9

I am using Entity Framework Model-First with Repository and Unit of Work patterns, the repositories return EF POCOs.

I assumed that I couldn’t add behaviour to my POCOs that are generated by Entity Framework, so my code is now full of things like XyzService which is a separate class implementing the business logic for the Entity Framework generated Xyz POCO.

I have the following questions:

  1. This has a bad code smell as not only do I have the EF POCOs, I have a service for each POCO. In addition to lots of classes, business logic is split outside of the business entity. Is this an example of the anaemic anti-pattern?

  2. If I stick with EF, is there any way I can add behaviour (i.e. through partial classes) or other means?

  3. Seeing the persistent ignorant patterns which use return business entities from data layer (in our case a repository), if I wanted to go from EF-MODEL -> REPOSITORY-DAL -> BIZ-ENTITY I see there would be a lot of two way mapping between the business entity and the EF model POCO. Can utilities such as Automapper gracefully handle complex relationships of nested objects that I am likely to face?

  4. To reduce duplicated business entities with their counterpart EF model entities, would I not be better of removing EF and just writing my own repository implementations using LINQ to SQL for each repository?

  5. Any recommended way that allows me to concentrate on the code (rather than target fixating on the EF model first as I have been), then still use Entity Framework at the end when I am ready to write the persistence layer, but avoiding a lot of extra work and mapping in doing so? Would EF Code-First be better in this regard?

If I have missed anything else of other technologies that can aid development (NHibernate for example) then please feel free to mention.

4

4 に答える 4

3
  1. しかし、このアプローチには利点がないわけではありません。たとえば、POCO とビジネス ロジックの分離を強制することで、そのロジックを分離し、依存性注入またはその他の手段を介して提供できるようになります。

  2. 部分クラスは複数のアセンブリにまたがることはできないことに注意してください ( MSDNから):

    同じ型の一部であることを意図したすべての部分型定義は、同じアセンブリおよび同じモジュール (.exe または .dll ファイル) で定義する必要があります。部分的な定義は、複数のモジュールにまたがることはできません。

    この制限は望ましくない場合がありますが、代わりに拡張メソッドを使用して必要な動作を実装できます。

  3. 私は Automapper を使用したことがないので、Ryan のアドバイスがここに当てはまります。

  4. & 5. Code-First を使用すると、特定のリポジトリの実装に影響を与えるため、これらをグループ化しました。Code-First を試したことがない場合は、一度試してみることをお勧めします。

リポジトリに関しては、扱っている POCO の種類と利用可能な操作の両方に関して、リポジトリが完全に汎用的であることを好みます。たとえば、LINQ を使用すると、特定の に基づいてGetアイテムを (たとえば、 として) 取得するメソッドをリポジトリに含めることができます。IEnumerable<T>Expression<Func<T, bool>>

私がこのアプローチを気に入っているのは、リポジトリに依存関係を注入できるようにし、標準の CRUD 操作をよりドメイン固有の操作から明確に分離しながら、消費者/派生クラスからコードを再利用する絶好の機会を提供するためです。

于 2012-12-18T08:38:51.130 に答える
3
  1. ええ、Fowlerによると、これはアンチパターンです。個人的には、このアンチパターンが不快すぎるとは思いませんが、不快に感じる人もいます。ここで最善の判断を下してください。気分が悪く、対処するのが面倒な場合は、変更してください。
  2. はい。部分クラスはこれに役立ちます。記述したパーシャルにビヘイビアーを入れることができます。
  3. はい。Automapper は、ネストされたオブジェクトにマッピングが設定されている場合、それらを自動的に処理します。
  4. 繰り返しますが、それはあなた次第です。EF に気が狂っている場合は、使用しないでください。機能するものと、使用中に気分が良くなるものを使用してください。
  5. Code firstはまさにこのために構築されました。
于 2012-12-17T21:36:37.790 に答える
3

デザインの本、パターンの本、著名なブロガーは問題ありませんが、私たち開発者は、たとえそれらの本や記事がどの状況でいつ適用されるかを理解するのに十分なコンテキストを提供しない場合でも、彼らが示唆するようにプロジェクトを開発する必要があると考える傾向があります。しないでください。

あらゆる用途に適したデザインなどというものはありません。技術的な点に焦点を当てているようですが、それで問題ありませんが、まず最も重要な質問に答えてください。要件はその設計にうまく適合していますか?

要件、制約、リソース、時間などの考慮事項があることを忘れないでください。これらは、設計を導くために必要なトレードオフに関与することを余儀なくされます。

例えば：

  • 本当にリポジトリが必要ですか? EF を使用してエンティティを直接取得するのは何ですか?
  • DataModels と BizModels が必要ですか? TransactionScripts だけを使用するとどうなるでしょうか。
  • UoWは必要ですか？なんで？EF はこれをうまく処理できませんか?

これらの質問に対する答えは絶対的なものではなく、要件、時間、予算などによって異なります。

さて、あなたの質問について私の考えを述べさせてください。

  1. はい、いくつかの理由で悪臭がします: a) POCO オブジェクトは、まあ... POCO であるべきです。これは、もちろんロジックを持つビジネスオブジェクトがあるためですが... POCO オブジェクトにはどのような種類のロジックがありますか? ?
  2. はい、これには xyzService の代わりに部分クラスを使用する必要があります。xysServices はまったくサービスではないため、これはより明確です。
  3. はい、Automapper はマッピングの問題を処理できます。ただし、おそらく多くのマッピングがあるという問題は解決しません。繰り返しますが、必要ない場合は避けてください。
  4. あなた（またはあなたの会社）には、それを行うのに十分なお金と時間がありますか? 今日では、絶対的な理由なしに ORM を避ける人はいません。だから、いや、やらないで！
  5. 同上 4。

これは私の意見。

于 2012-12-23T03:24:39.990 に答える
2

「Code First」パスをたどりたいと思うかもしれません。以前は部分クラスで EF モデリング ツールを使用していましたが、生成されたコードを制御できないなどの重大な問題が依然としてありました。モデラーに関する散発的な問題は言うまでもなく、リレーションシップを再作成する必要がありました。

「Code First」を使用すると、POCO をより適切に制御でき、データベースの移行や、T4 テンプレートなどを使用して好きな方法で POCO をスキャフォールディングする機能など、多くの追加の利点が得られます。

LinqToSQL には戻りません。EF の方が機能が豊富で、明るい未来があります。IMO です。EF は現在オープンソースです。私が直面した特定の問題を解決するために、ソースをいくつか調べました。

于 2012-12-22T13:51:35.250 に答える