4

これは、EFDBFirstモデルを使用した階層化設計に関するものです。

これまで、Entity Frameworkを使用したことはなく、エンティティのみを使用し、ドメイン/DTOサブフォルダーを使用して別のプロジェクトに配置しました。また、DataAccessLayer、Business Layer、MVCアプリケーションでも同じように参照され、通常のADO.Netクエリを使用してコードを記述し、エンティティのPOCOを準備しました。問題ない。

現在、Entity FrameworkDBFirstモデルを使用してアプリケーションを開発しています。DB Designが管理されていないため、このDBFirstモデルを選択しました。それはDBAによって行われます。

ここで古いシンプルなデザインを再利用しようと思いました。しかし、どこ/どのレイヤーをedmxファイルと生成されたPOCOクラスに正確に適合させるべきかわからない。DBFirstアプローチを使用する階層化アーキテクチャスタイルのサンプルは見つかりませんでした。

私はこれを参照しました。http://aspnetdesignpatterns.codeplex.comしかし、彼らはNHybernateを使用しています

これが古いデザインの概要です。ここに画像の説明を入力してください

デザイン/サンプルに関する提案があれば、大歓迎です。

編集：

以下の回答から、エンティティフレームワークは既存のエンティティ/ドメインレイヤーの名前をドメインレイヤーに変更し、生成されたPOCOクラスをそこに配置できるPOCOを生成すると思います。また、TDDのEFをラップするIRepositoryクラスのリストを使用して、.edmxをDataAccessLayerに保持することもできます。これは意味がありますか？または何か貴重なポイント？

アップデート：

現在、DataAccessLayerを削除し、model.edmxファイルとEFによって生成されたクラス、およびIRepositoryを実装するすべてのリポジトリクラスを持つエンティティレイヤーのみを保持しています。これをビジネスレイヤー、MVCにも参照します。私は正しくやっていますか？私は悪いデザインをしているように感じます:(提案/助けてください

4

4 に答える 4

1

以下の同様の種類の質問については、SOリンクを参照してください。

データベース ファーストのアプローチでは、コア レイヤーとインフラストラクチャ レイヤーをどのように分離すればよいですか?

お役に立てれば ！！

于 2013-12-12T12:10:23.977 に答える
1

残念ながら、最初にデータベースを作成するという決定によって深刻な障害が発生するため、Eric Evans の Domain-Driven Designに従ってAnti-Corruption レイヤーを使用する必要があります。

これは、絶対にコーディングしなければならないくだらないインターフェースが与えられたときに何をすべきかについての良い解決策です - 望むように振る舞うDBの周りにラップされたインターフェースを作ってください。EF クラスを、破損防止レイヤー自体以外に直接公開しないでください。

読み方の例は次のとおりです。

public class SomeReadService : ISomeReadService {
  public SomeViewModel Load(Guid id) {
    using (var dbContext = new DbContext()) {
      // Query the DB model, then *map* the EF classes to SomeVieWModel.
      // This way you are not exposing the shitty DB model to the outside world.
    }
  }
}

書き方の例は次のとおりです。

public class SomeRepository : ISomeRepository {
  public SomeDomainObject Load(Guid id) {
    using (var dbContext = new DbContext()) {
      // Map the EF classes to your domain object.  Same idea as before.
    }
  }
}

私は、別のチームが DB を設計することは大惨事になることをクライアントに実証しようとします (そして、私の経験ではそうなることが強く示されています)。DB を設計した方がよいことをクライアントに示すフィードバックを提供できる方法がないかどうかを確認してください。

于 2012-12-28T01:38:43.200 に答える
0

私の意見では、正しく使用されているEntity Frameworkは、個別のDALの必要性を否定します。私はEFを私のDALだと思っています。それはあなたがよりビジネスの部分に集中することを可能にします。EFがすべてのデータアクセスコードを代行します。ビジネスレイヤーでEFコンテキストを使用するだけです。私にとって、これはEFの最大のメリットの1つです。それがあなたのDALであること。

レイヤー（異なるアセンブリまたはアセンブリ内の異なるフォルダー）を分離する方法に応じて、POCOクラスを配置する場所によって異なります。異なるアセンブリ（ほとんどのプロジェクトではやり過ぎです）の場合、他のすべてのアセンブリによって参照される「共通」アセンブリがPOCOクラスを配置する場所です。別のフォルダの場合は、「Models」または「DomainModels」という名前のフォルダがその場所です。

特にMVCアプリケーションの場合、POCOクラスを「Models」フォルダー（「ViewModels」フォルダーもあります）に配置し、.Edmxを「Logic」と呼ばれることもあるBLLフォルダーに配置します。

テスト用に疎結合アーキテクチャが必要な場合は、EFコンテキストが独自のリポジトリパターンでラップされたRepositoriesという名前のフォルダが最適です。

于 2012-12-12T08:59:53.133 に答える
0

編集：

簡単な答えはデータ アクセス レイヤー (DAL)です

エンタープライズアーキテクチャが必要であり、ニーズに応じて変更されますが、あなたの場合、モデル駆動設計パターンが確実なソリューションです。MVCを使用でき、 PocoやNHibernetなどの他のエンティティからモデルを駆動できます。

code-firstやdb-firstについては重要ではありません。アーキテクチャの作成段階だけでも興味深いものです。

于 2012-12-25T20:56:22.343 に答える