10

プロジェクトの構造をできるだけきれいに保つのが好きです。サンプル：

--BlogApp.sln
  --BlogApp.Data
      BlogModel.edmx (the EF mappings)
      Post.cs (I end up having partial classes in here with attributes)
  --BlogApp.Domain
    --Entities
        Post.cs (I would like to have my POCOs here with all its additional logic)
    --Repositories
        PostsRepository.cs
  --BlogApp.Ui
      (standard MVC structure)

EFをORMとして使用すると、混乱してしまいます。プロジェクトを構成するための「クリーンな」方法を提案できる人はいますか? または、最も一般的に使用されている標準的なプロジェクト構造を提案することもできます。

4

2 に答える 2

22

私の好ましい構造は次のとおりです。

Solution
  -- Common
       - Shared features used accross all layers
       - You can also place interfaces for repositories and uow here
  -- Entities - shared among DataAccess, Business (and UI in small projects)
       - T4 template + partial classes + custom enums  
       - partial classes can contain methods with domain logic => domain objects 
  -- DataAccess - all EF dependent code here
       - EDMX or code first mapping
       - Repositories
       - UnitOfWork
  -- Business - not every project needs this assembly
       - Business services 
       - Logic like workflows
       - DTOs exposed to UI
  -- UI
       - Controllers
       - Views
       - ViewModels
于 2011-03-12T16:59:55.190 に答える
2

T4 テンプレートと Entity Frameworkに関するこの記事を確認してください。EF を介して生成されたエンティティ プロパティのカスタム属性を書き込むことができます。私はこれを数回行いましたが、その方法を理解した後、多くの時間を節約できました。あなたが言及したように、以前に部分クラスを使用してみましたが、EF で生成されたクラスは、カスタム属性で他のクラスを上書きしてしまいます。おそらく私は何か間違ったことをしていたのでしょうが、いずれにせよ、プロジェクト内のクラスの数を最小限に抑えているため、T4 テンプレート ソリューションの方がすっきりしているように見えるため、現在は T4 テンプレート ソリューションを好みます。

また、DB から EF モデルを更新してクラスを再生成しても、カスタム属性はそのまま残ります。ふぅ！

追加: ところで、通常、データ レイヤー内でモデル オブジェクトを定義して、EF のエンティティによってマップ/設定されます。または (さらに簡単に)、カスタム定義の POCO を使用せずに、EF によって生成されたエンティティを UI レイヤーまで使用します。

于 2011-03-12T14:48:04.933 に答える