建议简化我的架构... asp.net mvc答案

【问题标题】：Advice simplifying my Architecture... asp.net mvc建议简化我的架构... asp.net mvc
【发布时间】：2011-09-26 19:13:55
【问题描述】：

我目前有一个 UI 层/DomainService 层（域逻辑和服务驻留在此处）和用于持久性的 Repo 层，我使用 Ninject 来帮助解耦。

我的 UI 层非常简单 - 它将任务委托给服务层，但是我有一个非常复杂的应用程序，它依赖于登录用户，因此我的 CRUD 可能会变得非常复杂。

但我的问题是：我为几乎所有东西提供服务，然后连接到 GenericRepository。

例如 IOrder 与 IDBRepo 通信以获取订单信息，具体取决于访问订单的客户端，然后我有 Ishipping - 它也连接到 IDBRepo 并检索信息......当一个服务需要调用另一个服务时，它变得复杂，它们都连接到IDBRepo。

我已经设法取出 IUserSession 并将其提供给每个服务 - 但这对我来说似乎太复杂了......

设置测试时，我必须执行以下操作：

var db = new DBRepo();
var s1 = new OrderService(db);
var s2 = new ShippingService(s1,db);

然后要扩展我的部分/大部分服务，我必须添加一个 ILoggingService 和 INotificationService - 他们都需要访问数据库...

注意：我不是在寻找一个纯粹的 DDD，我正在努力利用最好的东西并让它发挥作用我想这是我的问题......

【问题讨论】：

UI 组件、服务实现或调用服务的后端系统有什么区别？服务的整个想法是向任何客户端公开一些功能或数据。（我不知道 c# 或 asp.net，所以我可能会在这里遗漏一些东西）
True... 这些服务驻留在我的核心层域服务中，老实说，我只在这一层中保留服务，所有其他层 (db) 将实现并提供该服务的功能，如果需要...

【解决方案1】：

Bob Cravens 卡车跟踪器是一系列值得阅读的好帖子，让您思考：

总的来说，如果可以避免的话，我认为拥有相互依赖的服务并不是一个好主意。如果您必须这样，请考虑使用依赖注入框架，例如 unity 或 spring.net 或 ninject。

【讨论】：

好吧，从头开始，我重新阅读了你的问题，发现你已经在使用 ninject 了。关键是如果你可以设计你的层，这样它们就不会相互依赖会更好。日志记录等是横切关注点，不能通过 AOP 处理。
问题是我的 INotificationService 并不是真正的横切 - 这是数据库驱动的，如果发生某些事件发送通知，或者这是横切？
我的 IOrderService 可能会很大，我的意思是如果我不拆分，因为一切都与订单有关...拆分它我也有单独的服务以实现可维护性，但它变得真实当一项服务需要另一项服务来做某事时，丑陋...
如果订单服务真的依赖于通知服务，那么就没有办法了——你需要它作为依赖。关键是，如果这对您很重要，您将需要设计您的服务类以最小化相互依赖性。不要忘记部分类等功能可以帮助解决此问题。