在ASP.NET MVC应用程序中的哪里放置数据处理和业务逻辑代码? [英] Where to put data manipulation and business logic code in ASP.NET MVC application?

问题描述

观看了Rob Conery的Kona应用程序的示例后，我发现他在IoC上使用了两件事-ISession，他拥有数据层代码和Services，在那里他拥有一些其他业务逻辑，当我们在其中处理数据时，我们需要执行这些业务逻辑数据存储.例如，我们不仅可以在数据库中添加一条记录，还可以更改另一条记录的属性，增加一些计数，取回一些东西，等等.我们需要将其他代码放在此处，然后将其放在这些服务中.

Having watched samples from Rob Conery's Kona application, I see that he is using two things with IoC - ISession, where he has data layer code and Services, where he has some additional business logic that we need to perform when manipulating data in datastore. For instance, we might not just add a record to the DB but also change properties of another record, increase some counts, take something back, etc. We need to put that additional code somewehere and he puts it in those services.

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

For instance, he has a CustomerService that manipulates Customers. This requires us to send ISession instance to the CustomerService, so that the CustomerService can use it to access the datastore.

现在，另一种实现方法是将其他代码放入Customer类本身，然后将ISession(或IRepository，无论我们使用什么术语)发送给该类.而且没有任何服务.通常，客户"，订单"，产品"等类是模型"类，因此将导致大型/繁重的模型类.

Now another way of doing it would be to put that additional code in the Customer class itself and send the ISession (or IRepository, whatever terminology we use) to that class. And not have any services. Typically, Customer, Order, Product, etc. classes are Model classes, so that would result in big/heavy model classes.

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

My question is, which solution is better? So far I did not have the need for that because I had most of the code in the controllers but now as my application grows, I need to make a decision on this and cleanup the controllers.

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

Currently I have: - fat controllers with business logic in it, - very atomic repositories, - very clean models and viewmodels.

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

Should I move to: - slim controllers, - repositories with more code, - models with business logic code (specifically should my model classes contain methods like Add(), Remove(), for instance Customer.Remove()??)

或 -苗条的控制器， -原子储存库， -仍然干净的模型， -服务(用于封装其他任何未包含的内容).

or to - slim controllers, - atomic repositories, - still clean models, - services (to encapsulate everything else that does not go into any of the previous).

推荐答案

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

I would recommend you having repositories containing atomic operations with the model classes and service layer which depends on those repositories to define business operations. The concept of AOP could be used to automatically start a SQL transaction at the beginning of each business operation and commit at the end or rollback in case of exception.

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

Finally controllers will use those service classes and convert between the domain models and view models.

这篇关于在ASP.NET MVC应用程序中的哪里放置数据处理和业务逻辑代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！