0

在 ASP.NET MVC 中实现 Onion 架构时，我的理解是我们应该/可以公开 IDataContext 接口，该接口可以在 UI 中注入和引用。

所以基本上在 ASP.NET MVC 中，我们可以这样做：

_context.Products.Add(myBadProduct);

那不是让 UI 层实现业务逻辑吗？我相信 Onion 的基本理念之一是它可以清楚地了解哪些代码进入了哪些层，并明确禁止 UI 层实现业务逻辑。

如果我们将存储暴露给 UI（有或没有SaveChanges能力），我们让 UI 开发人员实现自定义业务逻辑。

这可以通过仅通过诸如此类的域服务将所有操作暴露给底层 IDataContext 来“修复”。

用一句话总结我的问题：

我们应该允许 UI 层接触 IDataContext 还是应该只通过域服务公开所有上下文操作？如果我们公开 IDataContext，是否也可以公开在 IDataContext 中定义的 SaveChanges 方法（例如在实际的 EfDataContext 中实现）？

我认为 IDataContext 应该公开为只读（即没有 SaveChanges 功能），用于查询目的，而 C_UD 方法应该公开为域服务。对还是错？

4

2 回答 2

2

首先，我想提醒一下，即使onionarch.codeplex对于每个想要进入 Onion 架构的人来说都是一个非常好的起点（一切都非常简单），将其作为思考的来源是可以的，但是Matt Hidinger 的意图肯定不是在这里提供任何生产代码。

也就是说，恕我直言，这个决定取决于几个参数。

你是单独工作还是在一个大团队中工作？是否所有的开发人员都参与其中，相当不错的？你有DBA吗？你关心表演吗？

我在一家有很多不同开发人员的公司工作。我们的网站每分钟被点击大量时间，我们的 Web 应用程序正在访问一个非常庞大的数据库，该数据库由强大的 DBA 团队密切监控。如果我让开发人员对数据库创建自己的查询，我不确定每个人都会激活分析器来查看生成的 T-SQL 是否正常。控制每一个 Linq2Entities 查询是不可能的。这会导致性能问题和 DBA 的心脏病 :-) （当然缓存会有所帮助，但它并不能解决所有问题）。

因此，正如@DarinDimitrov 所说，这两种方法都是正确的，但从我的角度来看，我更喜欢不让消费者直接使用 IDataContext。

于 2013-04-22T15:00:40.450 回答
1

我们应该允许 UI 层接触 IDataContext 还是应该只通过域服务公开所有上下文操作？

实际上这两种方法是正确的。你会看到有人推荐第一个，其他人推荐第二个。例如，Ayende Rahien 写了一篇不错的博客文章，他解释说他更喜欢简单地将底层接口暴露给消费者，而不是最终使用以下方法的服务层：

  • 查找客户（ID）
  • FindCustomerWithAddresses(id)
  • FindCustomerWith..
  • ...

就我个人而言，我也倾向于这样做，但这又是主观的。就 SaveChanges 方法而言，我也会将其公开给消费者。

于 2013-04-18T06:42:41.593 回答