在ASP.NET MVC应用程序中放置数据操作和业务逻辑代码的位置?

mar*_*are 5 asp.net-mvc

看过Rob Conery的Kona应用程序的样本后,我发现他正在使用IoC - ISession,他有数据层代码和服务,他在操作数据存储区中的数据时需要执行一些额外的业务逻辑.例如,我们可能不仅仅是向DB添加记录,而且还改变了另一条记录的属性,增加了一些计数,取回了一些东西等等.我们需要将这些额外的代码放在一边,并将它放在那些服务中.

例如,他有一个操纵客户的CustomerService.这要求我们将ISession实例发送到CustomerService,以便CustomerService可以使用它来访问数据存储区.

现在另一种方法是将其他代码放在Customer类本身,并将ISession(或IRepository,无论我们使用的术语)发送到该类.而且没有任何服务.通常,Customer,Order,Product等类是Model类,因此会导致大/重模型类.

我的问题是,哪种解决方案更好?到目前为止,我没有必要,因为我在控制器中有大部分代码,但现在随着应用程序的增长,我需要对此做出决定并清理控制器.

目前我有: - 具有业务逻辑的胖控制器, - 非常原子的存储库, - 非常干净的模型和视图模型.

我应该转到: - 超薄控制器, - 包含更多代码的存储库, - 具有业务逻辑代码的模型(特别是我的模型类包含Add(),Remove()等方法,例如Customer.Remove()??)

或者 - 苗条的控制器, - 原子库, - 仍然是干净的模型, - 服务(以封装其他任何不属于前者的东西).

Dar*_*rov 7

我建议您使用包含模型类和服务层的原子操作的存储库,这些存储库依赖于这些存储库来定义业务操作.AOP的概念可用于在每个业务操作开始时自动启动SQL事务,并在结束时提交或在异常情况下回滚.

最后,控制器将使用这些服务类并在域模型和视图模型之间进行转换.

  • 同上,除了我转换为服务内部的视图模型,因此控制器无法调用我的域模型上的方法. (2认同)