【问题标题】:Duplicating POCO code in different layers with code-first migrations使用代码优先迁移在不同层中复制 POCO 代码
【发布时间】:2016-11-08 18:52:49
【问题描述】:

我对使用实体框架感兴趣 - 使用新数据库进行代码优先迁移,我对在数据和业务层中复制 POCO 代码有一些疑问/疑虑。

这个想法是有一个数据访问层,其中包含我的 POCO 实体,所有这些都用数据库模式类型项进行装饰,例如字符串长度、与开箱即用的外键相关的东西,以及其他任何东西。该层还将作为一个存储库,返回标量值、实体、聚合和 IEnumerables。

上面是业务层,它将处理与存储库的对话,以及一堆业务逻辑。

顶部是表示层。该层与业务层对话,对数据层一无所知——它所理解的只是视图模型。我将在这一层实现 MVC 模式,只使用视图模型。

我遇到的问题与我应该在哪里进行视图模型和数据模型之间的映射有关。如果我在表示层中定义视图模型,业务层将不知道它们的存在。

  • 我是在业务层中定义视图模型更好,还是我需要业务层中的一组域模型,表示层会知道并能够对其执行映射?
    • 额外的一组域模型是否会严重重复数据层中定义的模型?

【问题讨论】:

  • 模型必须位于客户端和业务层都可以引用的地方。这样,它们就充当了两层之间的数据契约。您可以让业务层以您认为合适的方式与 DAL 交互,并始终将商定的数据合同返回给客户端。这意味着您的模型与您的视图和控制器位于一个单独的项目中。
  • 我曾想过 - 在我的 MVC 项目中拥有一个空模型文件夹似乎很奇怪,但也许这只是我需要克服的问题。我希望了解其他我不知道存在的选项:)
  • 你确定业务逻辑应该引用视图模型吗?
  • 我不敢说实话。希望能感受一下其他人的经验。将视图模型交给表示层的想法听起来不错,但我想知道是否有可能遇到的陷阱。

标签: c# asp.net-mvc entity-framework-migrations


【解决方案1】:

根据项目的范围,我通常使用以下两种方法之一:

1) 拥有一组独立于所有层的领域模型,然后让所有层引用它们。 优点:图层仍然是独立的,没有模型重复,不需要映射图层模型。 缺点:领域模型的变化会影响所有层,例如数据库更改可能会破坏显示

2) 在每一层都有模型。业务层将自己的模型映射到数据层的模型,表示层将其模型映射到业务层的模型 优点:每一层都做一件事,底层模型的变化不会通过层传播 缺点:模型可能重复,需要维护映射

第一种方法最适合较小的应用程序和“直接更新”场景,第二种方法更适合具有多个移动组件的大型项目。

附: “在业务层定义视图模型”是绝对不行的。

【讨论】:

  • 感谢您分解不同的选项。我认为在一个通用程序集中定义我的所有模型是有意义的。唯一感觉奇怪的是,我在数据访问之外的层中使用数据注释来获取数据库模式信息。
  • 如果这让您感到奇怪,您可以始终保持 poco 的清洁,并使用 EntityTypeConfiguration 将实体映射到单独的程序集中
猜你喜欢
  • 1970-01-01
  • 2016-01-27
  • 2016-05-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多