使用 EF、存储库、实体清理解决方案(项目)结构

发布于 2024-10-21 07:14:01 字数 485 浏览 7 评论 0原文

我喜欢保持项目的结构尽可能干净。 示例:

--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 时,我最终陷入了混乱。有人可以建议一些“干净”的方式来构建该项目吗?或者也许您可以建议一些最常用的标准项目结构。

I like to keep the structure of the project as clean as possible.
Sample:

--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)

I end up with mess when using EF as my ORM. Could anybody suggest some "clean" way to structure the project? Or maybe you could suggest some standard project structure that is most commonly used.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

烟沫凡尘 2024-10-28 07:14:01

我的首选结构是:

<前><代码>解决方案
- 常见的
- 所有层使用的共享功能
- 您还可以在这里放置存储库和uow的接口
-- 实体 - 在 DataAccess、Business(以及小型项目中的 UI)之间共享
- T4模板+部分类+自定义枚举
- 部分类可以包含具有域逻辑的方法=>领域对象
-- DataAccess - 所有 EF 相关代码均位于此处
- EDMX 或代码优先映射
- 存储库
- 工作单元
-- 商业 - 并不是每个项目都需要这个组件
- 商业服务
- 类似工作流程的逻辑
- DTO 暴露给 UI
-- 用户界面
- 控制器
- 景观
- 视图模型

My preferred structure is:

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
以歌曲疗慰 2024-10-28 07:14:01

查看有关 T4 模板和实体框架的文章。您可以为通过 EF 生成的实体属性编写自定义属性。我已经这样做了好几次了,在弄清楚如何做之后,现在节省了大量时间。正如您提到的,我之前尝试过使用部分类,但我的 EF 生成的类最终会使用自定义属性覆盖另一个类。也许我做错了什么,但无论如何,我现在更喜欢 T4 模板解决方案,因为它对我来说看起来更干净 - 最大限度地减少项目中的类数量。

此外,当您从数据库更新 EF 模型并重新生成类时,您的自定义属性仍然存在。 ftw!

添加
顺便说一句,我们通常在数据层中定义模型对象,以便由 EF 的实体映射/填充它们。或者(甚至更简单)使用 EF 生成的实体一直到 UI 层,而无需自定义 POCO。

Check out this write up on T4 Templates and the Entity Framework. You can write in custom attributes for entity properties generated via EF. I've done this several times, and after figuring out how to do it, it now saves a lot of time. I've tried using partial classes before as you mention, but my EF-generated class ends up overwriting the other with the custom attributes. Perhaps I was doing something wrong, but in any case, I now prefer the T4 template solution because it seems cleaner to me - minimizing on number of classes within a project.

Also, when you update your EF model from DB and the class is regenerated, your custom attributes are still in place. ftw!

ADDED:
By the way, we typically define our model objects within the Data layer to have them mapped/populated by EF's entities. Or (even simpler) use the EF-generated entities all the way through to the UI layer without custom defined POCOs.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文