タグ付けされた質問 「asp.net-mvc」

ASP.NET MVCフレームワークは、モデルビューコントローラー(MVC)パターンを実装するMicrosoft Webアプリケーションフレームワークです。

2
.NET MVCプロジェクトアーキテクチャ/レイヤー
中規模のMVC Webアプリケーションのアーキテクチャを計画するとき、レイヤーを可能な限り分離してテストしやすいように実装するにはどうすればよいですか?(基本的にベストプラクティスに従います)データアクセスとして最初にコードを使用しているとしましょう。 「ビジネスロジック」の定義、およびデータレイヤーとのやり取りをどのように定義するかについて、私は苦労しています。車両販売アプリケーションを例にとると、ビジネスロジックは、特定の車両の税帯の計算、ガロンあたりのマイル統計の比較などのタスクを実行するクラスでしょうか。ビジネスエンティティ(例:車、バン、オートバイ)については、これらをDataContextクラスと共にデータレイヤーに配置します。 また、ビジネスとは対照的に、アプリケーションロジックを構成するものは何ですか。セッション/ユーザー入力の検証などを推測していますか? したがって、たとえば、車のコントローラは、タイプと最良のmpgでフィルタされた上位10台の車をリストするアクション/ビューの結果を返す場合があります。たとえば、ICarRepository「リポジトリ」/ DIを使用して「carRepo」をコントローラに注入したとします。アクションメソッドのパラメータから車をフィルタリングします。var cars = carRepo.getCarsByType("hatchback"); したがって、リポジトリを使用してデータアクセスの知識をコントローラーから除外し、ドメインモデルを使用してビジネスロジックをコントローラーから除外しました-var result = new MpgCalculator(cars); -DBからエンティティをロード/フィルタリングするだけではなく、最高の燃料効率を計算するために追加のロジックを実行する必要があるため、電卓クラスが必要だとしましょう。これで、ビューをレンダリングするためのデータセットがあり、リポジトリを使用してデータアクセスレイヤーから取得し、ドメイン固有のオブジェクトを処理して、そのデータに対してビジネス関連のタスクを実行します。 ここで間違いをしていますか?それでもリポジトリパターンを使用する必要がありますか、それともORMを分離してテストするためにインターフェイスに対してコーディングするだけですか?このトピックでは、具体的なデータアクセスクラスdbcontextがデータレイヤーにあるので、インターフェイス定義をドメイン/ビジネスレイヤーに入れる必要があります。つまり、データアクセステクノロジーが変更されても、他のレイヤーは影響を受けません。 これまでに調べたことから、私の構造は次のようになります。 MVCインターネットアプリケーション ->標準インターネットプロジェクト-ここのモデルはViewModelsです ドメイン/ビジネスレイヤー ->コントローラーが関連するビューに渡す前にデータレイヤーからドメインエンティティを処理するために使用できるビジネス固有のクラス/モデル リポジトリの抽象化が必要ですか?->特にORMを使用する場合、これについて多くの議論が聞こえます データレイヤー ->エンティティクラス(Car、Van、Motorcycle)、DbContext-具象データアクセステクノロジーレイヤー

3
エンティティフレームワークエンティティ-Webサービスからのデータ-最高のアーキテクチャ?
現在、いくつかのWebアプリケーションでEntity FrameworkをORMとして使用しています。これまで、すべてのデータが単一のデータベースに格納されているため、これが適しています。リポジトリパターンを使用しており、これらを使用するサービス(ドメインレイヤー)があり、EFエンティティをASP.NET MVCコントローラーに直接返します。 しかし、データベース内のユーザーに関連する追加情報を提供するサードパーティのAPI(Webサービスを介して)を利用する必要が出てきました。ローカルユーザーデータベースに、追加情報を取得するためにAPIに提供できる外部IDを保存します。利用できる情報はかなりありますが、簡単にするために、そのうちの1つはユーザーの会社(名前、マネージャー、部屋、役職、場所など)に関連しています。この情報は、単一の場所で使用されるのではなく、Webアプリ全体のさまざまな場所で使用されます。 だから私の質問は、この情報を入力してアクセスするのに最適な場所はどこですか?さまざまな場所で使用されているため、Webアプリケーションで使用する場合は常にアドホックベースでフェッチすることはあまり意味がありません。そのため、この追加のデータをドメインレイヤーから返すことは理にかなっています。 私の最初の考えは、EFエンティティ(EFUser)を含むラッパーモデルクラス、および新しい情報を含む新しい 'ApiUser'クラスを作成することでした-ユーザーを取得すると、EFUserを取得し、追加のAPIからの情報、およびApiUserオブジェクトを設定します。ただし、これは単一のユーザーを取得する場合は問題ありませんが、複数のユーザーを取得する場合は失敗します。ユーザーのリストを取得するときにAPIをヒットすることはできません。 私の2番目の考えは、ApiUserを返すEFUserエンティティにシングルトンメソッドを追加し、必要なときにそれを設定することでした。必要なときだけアクセスするので、これは上記の問題を解決します。 または、最後の考えは、データベースにデータのローカルコピーを保持し、ユーザーがログインしたときにAPIと同期することでした。これは単なる同期プロセスであるため、最小限の作業であり、ヒットのオーバーヘッドはありません。ユーザー情報を取得するたびにDBとAPIを使用します。ただし、これらはデータを2か所に保存することを意味し、しばらくログインしていないユーザーのデータが古くなっていることも意味します。 このようなシナリオを処理するための最善の方法についてアドバイスや提案はありますか?

4
単体テストで、なぜリポジトリを2回作成するのですか?
先日、ユニットテストについて少し読んでいて、人々がリポジトリインターフェイス(つまりIExampleRepository)を作成してから、実際のリポジトリ(public class ExampleRepository : IExampleRepository)とユニットテストに使用するリポジトリ()を作成する例をいくつか見ましたFakeExampleRepository : IExampleRepository。 IExampleRepositoryそれらはと同じ方法を実施したExampleRepositoryが、異なるLINQクエリと、。 ここの目的は何ですか?コードの単体テストの一部は、メソッドが正しく機能することを確認することだと思いましたか?しかし、「実際の」クエリとテスト内のクエリの2つのまったく異なるクエリを使用すると、テストはどの程度意味がありますか?

1
ASP.NETで適切なサービスレイヤーを構築する方法
私はいくつかの質問、優れたサービス層を構築するための技術を調べてきましたが、これに関して私が助けを必要とするいくつかの質問があります。 最初に、私が要件について持っているもののいくつかの情報。現在、スパイダーウェブのような方法で相互に通信する多くのWebアプリケーションがあります(すべて、Webサービスとデータベースデータを介して、混乱する方法で相互に通信します)。 これを変更して、すべてのアプリケーションがサービスレイヤーを通過するようにしたいと思います。サービスレイヤーでは、キャッシュを使用して作業し、共通の機能などをカプセル化できます。 サードパーティのクライアントがサービスからの情報を利用できるように、このレイヤーにもWeb APIが必要です。 問題は、たとえばMVC4 Web APIでサービスレイヤーを構築する場合、webAPIを使用してアプリケーション間で通信する必要がないということです。つまり、URLを構築してJSON / Xmlを消費する必要があります。それはあまり効果的に聞こえません。エンティティとWCFを使用してアプリケーション間の通信を行う方が良い方法だと思いますが、Web APIの魔法を失う可能性がありますか? したがって、問題は、サービス層をWeb API(JSON / XML)とエンティティを含むよりバックエンドのサービス層の両方として利用する方法があるかどうかです。2つの異なるサービスレイヤーを使用せざるを得ない場合、一部の機能や他の悪いことを複製する必要があるかもしれません。 質問が十分に明確であることを願って、さらに情報が必要かどうか尋ねてください。

3
ASP.net 5とEF7でリポジトリはもう必要ですか?
EFチームにgithubで質問を投稿しました。ここでこの質問をする方がよいとの返信がありました。コピーしてここに貼り付け、リンクとして他のユーザーがGitHubでいくつかの返信を確認できるようにします。 質問:私はいくつかの調査を行っていましたが、誰かがDBContextクラスの24行目で次のように述べていると指摘しました DbContextは、作業単位パターンとリポジトリパターンの組み合わせです。 これは、EFをリポジトリーに抽象化し、インターフェースを使用してそれをコントローラーに注入する必要がなくなったことを意味しますか? Githubの元の投稿:https : //github.com/aspnet/EntityFramework/issues/4899 私がこれを尋ねる理由は、GetById、GetByName、GetWithIncludesABC、GetWithIncludes123などの多くのメソッドをリポジトリに追加しているように見えて、私の心の中でリポジトリを汚しているように思われるからです。

3
ASP.Netの3層アーキテクチャとMVC(モデル、ビューコントローラー)の違い
3層アーキテクチャがASP.NetのMVC(モデル、ビューコントローラー)とどのように異なるかを知りたいのですが、同じアーキテクチャが適用されるようです。 3階層では、我々は持っているUser Services Layer、BusinessLayerとDataAccessLayer、私たちは持っている一方でModel、View、とController。これは同じアーキテクチャのようです。 2つのアーキテクチャの実際の違い、各レイヤーの違いについて説明できますか?

6
RazorまたはXSLTは私のプロジェクトに適していますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は、本質的に2つの部分に分割されるシステムの設計の初期段階にいます。1つはサービスで、もう1つはODataやXMLなどのデータを提供するサービスとのインターフェースです。アプリケーションは、MVCアーキテクチャパターンに基づいています。ビューについては、ASP.NETでXSLTまたはRazorの使用を検討しています。 XSLTまたはRazorは、元のXMLまたは応答がモデルを表す場合、XSLTまたは 'Razorビュー'がビューを表す場合の懸念を分離するのに役立ちます。この例では、コントローラーを省略します。最初の設計提案ではXSLTを推奨していますが、よりフレンドリーなビューエンジンとしてRazorを使用することを提案しました。 これらは私がRazor(C#)に提案した理由です: より複雑なページの操作と作成が簡単になります。 * ML以外の出力(csv、txt、fdfなど)を簡単に生成できます 冗長でないテンプレート ビューモデルは強く型付けされており、ブール値や日付値など、XSLTは規則に依存する必要があります。 マークアップはより近づきやすいです。たとえば、nbsp、改行の正規化、属性値の正規化、空白ルール 組み込みのHTMLヘルパーは、DTO属性に基づいてJS検証コードを生成できます 組み込みのHTMLヘルパーはアクションへのリンクを生成できます そして、かみそりよりもXSLTの議論は: XSLTは標準であり、今後も何年も存続します。 誤ってロジックをビューに移動するのは難しい プログラマー以外の方が簡単です(同意しません)。 過去のいくつかのプロジェクトで成功しています。 データ値はデフォルトでHTMLエンコードされます 常に整形式 だから私はどちらかの側の意見、推奨事項、または同様の選択をする経験を探していますか?
9 c#  asp.net-mvc  xslt  razor 

5
開発前に最新のアプリケーションをモデリングするための標準は何ですか?
私は最初のエンタープライズレベルのアプリケーションに取り掛かっています。コードを1行もタップする前に、チームでASP.NET MVC C#アプリケーション全体をモデル化してください。 更新:これは、いつアプリケーションを文書化/モデル化するかについての哲学的議論を意図したものではありませんでした。文書化/モデル化の「方法」についてのみ回答を提供してください。 真実は、私がこの部門で常に失敗したことがあり、アプリケーションをこれまで実際にモデル化したことがないということです。これを行うための標準的な方法は何ですか?どのタイプの図を使用する必要があり、ドキュメントはどのように見えますか?サンプルの図とドキュメントへのリンクは高く評価されています。 検索するとき、私はネット上で多くのことを見つけることができますが、これを行う方法について現在のコンセンサスがあるかどうかを確認したいと思いました。 前もって感謝します! おわりに 私はこれがそんなにねばねばした主題であるとは知りませんでした。明白な論争を取り除き、有用な回答を提供してくれた皆さんに感謝します。控えめに言っても興味深い議論でした:) 私が発見した別の便利なリンクはこれです:https : //stackoverflow.com/questions/61487/do-you-use-uml-in-agile-development-practices/61519#61519

3
Asp Net MVCのビューごとに1つのバンドルを持つことは良い習慣ですか
バンドルとミニファイはすべて最適化とページの読み込みを高速化することを目的としているため、スクリプトごとに1つのバンドルとスタイルごとに1つのバンドルを作成し、ビューごとに1つのバンドルを作成すると、ブラウザに必要なすべてのスクリプトとスタイルを読み込むことができます。最大で2つのリクエストを作成します。それでは、私が持っているとしましょう_Layout.cshtml、私は3つのJSファイルを必要な場所bootstrap.js、jquery.jsおよびいくつかのcustom1.js私は1つのバンドル、このようなものを作成することができます。 bundles.Add(new ScriptBundle("~/bundles/layout").Include( "~/Scripts/bootstrap.js", "~/Scripts/jquery.js", "~/Scripts/custom1.js")); その後の私は別のビューとしましょうUser.cshtml、私は必要bootstrap.js、jquery.jsとcustom2.js、再び私は1つのバンドルを作成します。 bundles.Add(new ScriptBundle("~/bundles/user").Include( "~/Scripts/bootstrap.js", "~/Scripts/jquery.js", "~/Scripts/custom2.js")); 同じアプローチをスタイルバンドルに使用できます。しかし、私が見るところによると、このように行うことは一般的な習慣ではありません。通常、バンドルはタイプベースで作成されます。たとえば、1つはブートストラップ用、1つはjquery用、1つはカスタムjs / cssファイル用などです。バンドルが多いほどサーバーへのリクエストが多くなるため、ページの読み込み時間。また、最初に説明した方法で問題を解決することは何ですか?

4
MVC-ビュー間でコンテキスト情報を共有する
長い投稿は申し訳ありません。質問があります。ただ我慢してください。 少しのコンテキスト 私たちは、さまざまなユーザー設定、ユーザーが所属するグループ、ユーザーの出身地などに基づいて大幅に適応する必要があるサイトを持っています。以前はページのモデルに関連ビットを含めていたため、ページに、ユーザーが特定の年齢を超えているかどうかを示すテーブルがある場合、モデルでは次のようにします。 //model public PageModel { public bool ShowTable {get;set;} } //controller public PageController { public ActionResult ShowPage() { var model = new PageModel() { ShowTable = User.Age > 21 }; return View(model); } } //view @if(Model.ShowTable) { <table>Some Html here</table> } これは、どのユーザーに何を表示すべきかを知るためにすぐに非常に複雑になりました。この問題に対処するために、特定のものが表示または非表示になるタイミングに関するすべてのロジックを一元化しました。このクラスを呼び出したUserConfigurationところ、(ほとんどの場合)何を表示すべきかを示すブール値を返す一連の関数が含まれていました。これにより、ユーザーに表示する必要がある一連の仕様とテストを設定できました。UserConfigratuion次に、これは、すべてのページモデルが継承する必要がある基本クラスに配置されました。そのため、現在、次のようになっています。 //UserConfiguration public UserConfiguration { private readonly …
8 c#  mvc  asp.net-mvc 

7
一般的なタスクを実行し、アプリケーション全体から呼び出されるメソッドに静的クラスを使用する必要がありますか?
私は最後の数時間を費やして、staticクラスの使用について読み、それらを使用する必要があるかどうかを理解しようとしましたが、それでも何らかの結論には至っていません。議論はどちらにでも行くことができるようです。私のアプリケーションでは、「ヘルパークラス」と呼ばれるものを作成しました。これには、非常に一般的なタスクを実行し、アプリケーション全体(ASP.Net MVCWebアプリを使用C#)から呼び出されるメソッドが含まれています。簡単な質問は、それらが本当に静的かどうかです。 ? これが私のヘルパーの例です。 public static class ActiveDirectoryHelper { public static PrincipalContext GetPrincipalContext(string ouName) { var fullOUName = string.Concat("OU=", ouName,",DC="); return new PrincipalContext(ContextType.Domain, "", fullOUName, ConfigurationManager.AppSettings["ServiceAccountUser"], ConfigurationManager.AppSettings["ServiceAccountPassword"]); } public static PrincipalSearcher GetAllUsersInOU(string ouName) { var principalContext = GetPrincipalContext(ouName); var userPrincipal = new UserPrincipal(principalContext); return new PrincipalSearcher(userPrincipal); } public static UserPrincipal …

7
単一の日付と日付範囲の両方を表すことができるプロパティ:適切にモデル化する方法は?
私は2つの方法で「送料見積もり」を表すことができるシステムで働いています。 特定の日付:アイテムはその日付で出荷されることが保証されています 日間隔:アイテムは今日から「X to Y」日で発送されます モデルに関する情報は、意味的には同じで、「発送予定」です。配送見積もりの​​情報をシステムから取得すると、見積もりが最初の形式か2番目の形式かがわかります。 このための現在のモデルは次のようになります。 class EstimattedShippingDateDetails { DateTime? EstimattedShippingDate {get; set;} Range? EstimattedShippingDayRange {get; set;} } Range 整数の「始まり->終わり」をラップする単純なクラスです。 struct Range { int Start {get; set} int End {get; set} public override ToString() { return String.Format("{0} - {1}", Start, End); } } 推定モデルのプロパティの1つだけが入力されるため、このアプローチは好きではありません。一方のプロパティでnullをテストし、もう一方のプロパティにデータがあると仮定する必要があります。 各プロパティは、ユーザーには異なる方法で表示されますが、現在のスイッチングロジックが存在するカスタムMVC DisplayTemplateを使用して、UIの同じ場所に表示されます。 @Model EstimattedShippingDateDetails @if …

2
階層化アプリケーションの承認ルールはどこに適用されますか?
この質問は、私を混乱させる私の申請の規則を適用することについてです。 コントローラはサービスを使用しており、サービスはリポジトリを使用しています。 public class CommentController: ApiController{ [HttpPost] public bool EditComment(Comment comment){ commentService.Update(comment); } } public class CommentService{ ICommentRepository repository; .... .... public void Update(Comment comment){ repository.Update(comment); } } ユーザーが認証されると、コメントを更新できます。 ただし、ユーザーは自分のコメントを編集する必要があります。 ただし、管理者はすべてのコメントを編集できます。 ただし、指定した日付以降はコメントを編集できません。 部門で編集 そして、私はこれらのルールのようなものを持っています。 サービスレイヤーで「ユーザー編集独自のコメント」ルールを適用すると、Update methotを変更し、コントローラーのパラメーターUser.Identity.Nameを渡します。 public class CommentService{ ICommentRepository repository; .... .... public void Update(string updatedByThisUser, Comment comment){ // …

1
モデルは使用せず、ビューモデルのみ
私は新しいMVC 5プロジェクトをゼロから始めています。私はEF 6(Database First)とIdentity 2.0を使用しています。 私のソリューションは、3つの異なるプロジェクトで構成されています。データ(.edmxと私のDBコンテキストがある場合)、リソース(ローカライズ目的)、およびWeb(Webプロジェクト自体)です。 デフォルトでは、すべてのビューにViewModelsを使用しています。新しいビューを作成するたびに、最初に行うのはViewModelを追加することです(ViewModelがそれらのビューに接続されている場合、それらをすべて同じファイルに保持します。たとえば、AccountViewModelに保持するユーザーアカウントに関連するすべてのViewModelを保持します)。 。これまでのところ、これにより状況が非常にシンプルになり、以前に抱えていたいくつかの問題が解決されました。 しかし、私は疑問に思っています、モデルを使用することはまったく意味がありますか?現在使用しているのはIdentityの1つだけです。これはデフォルトで作成され、Identityに固有で必要なApplicationUserとApplicationDbContextが含まれています。それ以外は、すべてViewModelsです。 データプロジェクトは、アプリケーションの「モデル」と見なされますか?したがって、私は実際にモデルを使用しています。それは、Web \ Modelsに保持する一連のクラスではなく、「モデル」(エンティティによって作成されたBLオブジェクト)が格納される別個のプロジェクトです。そう思いますが、よくわかりません。 これは正しいアプローチですか、それとも将来的に問題が発生する可能性がありますか?これはWebプログラミングへの私の最初の取り組みなので、アドバイスをいただければ幸いです。
8 c#  .net  mvc  asp.net  asp.net-mvc 

3
サービスレイヤーのあるリポジトリパターン-分離が多すぎますか?
リポジトリパターンを使用するMVCサイトがあります。MVCスタイルを十分に使用しているようには思えないので、その一部を再構築する準備をしています。しかし、私もそれを実行したいので、フロントエンドが変更された場合は、交換しやすくなります。 これが私が現在持っているものです モデル-一部のモデルには、エンティティ/クラスが直接含まれています。(ログインモデルにはCustomerクラスが含まれます。これは、Customerテーブル/リポジトリクラスと直接相関しています)ビュー-ビューの一部にリポジトリクエリが含まれています-つまり _customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name); コントローラー-ここではそれほど大きな問題ではありません。コントローラーはいくつかのレポクエリを呼び出します。一部のコントローラーはいくつかのサービスを使用してレポを呼び出します-すなわち _customerService.GetAllCustomers() 呼び出す _customerRepo.Query().All(); これが私の考えです。 1)モデルには、ビューに表示する必要があるデータのみを含める必要があります。Customerテーブル/オブジェクトのすべてのプロパティがビューに表示されている場合でも、ビューがデータベースアーキテクチャまたはバックエンドオブジェクトについて何も認識しないように、それらを独自のモデル/クラスに書き直す必要があります。 2)ビューはモデルオブジェクトにのみアクセスする必要があります 3)(そして、これは私がとるべき道に苦労しているところです) a)コントローラー(またはMVC側のどこか)は、repo / servicesから返されたオブジェクトデータを変換してモデルに変換するコードである必要があります。このコードをモデルコンストラクターに配置できると想定していますが、検証エラーがある場合に備えて、DIはデフォルトの空のコンストラクターを想定していることに気付きました b)コントローラは、データを取得するための適切な名前の付いたメソッド(つまり、_customerRepo.GetAllCustomers())でrepoインターフェースを呼び出します c)コントローラはサービス層にのみアクセスします。サービスレイヤーは、リポジトリレイヤーとやり取りする唯一のものです。 モデル、コントローラー、サービス、リポジトリのレイヤーを抽出しすぎていますか?サービスレイヤーはすべてリポジトリで実行できるため、オーバーヘッドが多すぎませんか? オブジェクト/ビジネスエンティティをモデルに変換するための推奨アプローチは何ですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.