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

时间:2010-06-28 11:05:44

标签: asp.net-mvc

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

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

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

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

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

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

或 - 超薄控制器, - 原子库, - 仍然干净的模型, - 服务(封装以前没有进入任何其他内容的所有其他内容)。

1 个答案:

答案 0 :(得分:7)

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

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