在ASP.NET MVC中实现Onion架构时，我的理解是should/could expose the IDataContext interface，可以在UI中注入和引用。
所以基本上在ASP.NET MVC中，我们可以这样做：
_context.Products.Add(myBadProduct);
这是否允许UI层实现业务逻辑？我相信洋葱的基本理念之一是它清楚地理解代码进入哪个层并明确禁止UI层实现业务逻辑。
如果我们将存储暴露给UI（具有或不具有SaveChanges功能），我们让UI开发人员实现自定义业务逻辑。
这可以通过仅通过域服务such as this将所有操作公开给基础IDataContext来“修复”。
将我的问题总结为一句话：
我们是否应该允许UI层触及IDataContext，还是应该仅通过域服务公开所有上下文操作？如果我们公开IDataContext，是否也可以公开在IDataContext中定义的SaveChanges方法（例如在实际的EfDataContext中实现）？
我认为IDataContext应该作为readonly公开（即没有SaveChanges功能），用于查询目的，而C_UD方法应该作为域服务公开。是对还是错？
答案 0 :(得分：2)
首先，我想提醒一下，即使onionarch.codeplex对于想要进入洋葱架构的每个人来说都是一个非常好的起点（一切都非常简单），提到它作为思考还可以，但Matt Hidinger的意图肯定不是在这里提供任何生产代码。
那就是说，恕我直言的决定取决于几个参数。
您是单独工作还是在大型团队中工作？所有的开发人员都参与其中，非常好吗？你有DBA吗？你关心表演吗？
我在一家拥有很多不同开发人员的公司工作。我们的网站每分钟都要花费大量时间，我们的网络应用程序正在访问一个非常庞大的数据库，该数据库由一个强大的DBA团队密切监控。如果我让开发人员为数据库创建自己的查询，我不确定每个人都会激活一个分析器来查看生成的T-SQL是否正常。无法控制每个Linq2Entities查询。这会导致性能问题和DBA的心脏病发作:-)（当然缓存会有所帮助，但它并不能解决所有问题）。
所以，正如@DarinDimitrov所说，这两种方法都是正确的，但从我这边来看，我不希望消费者直接使用IDataContext。
答案 1 :(得分：1)
我们是否应该允许UI图层触及IDataContext，或者我们应该如何 仅通过域服务公开我们的所有上下文操作？
实际上这2种方法都是正确的。你会看到有人推荐这个人和其他人推荐第二个人。例如Ayende Rahien写了一个nice blog post，他解释说他更喜欢简单地将底层接口暴露给消费者，而不是通过以下方法结束服务层：
就我个人而言，我也倾向于这样做，但这又是主观的。就SaveChanges方法而言，我也会将其暴露给消费者。