当在ASP.NET MVC项目实施库数据库，它是正确的把业务逻辑转换，或可能是更好的把逻辑控制器类？或者使用额外的服务和辅助类的操纵数据？

When implementing Repository for database in ASP.NET MVC project, is it correct to place business logic into it or may be better to place logic in controller class? Or use additional service and helper classes for manipulating data?

推荐答案

最终没有为您的业务逻辑的完美的地方，除了它自己的图层（如模型层的一部分）。通常情况下，你可以逃脱不同的实现，但也有权衡在任何情况下。

Ultimately there isn't a perfect place for your business logic besides its own layer (as part of the "Model" layer). Often you can get away with a different implementation, but there are trade offs in every case.

在权衡创造另一层业务逻辑是，你必须真正封装的code。如果你过于激进，也可能让你的实体和领域模型之间有一些重复（如果你的数据库的语义关系已经照顾你理财周报的逻辑）。

The trade off to creating another layer for the business logic is that you have to actually encapsulate your code. If you're too aggressive, you might also get some duplication between your entities and your domain model (if your DB's relational semantics already take care of your buiness logic).

查看

视图是最脆弱的部分您的应用程序，因为它是最容易的部分改变。

The view is the most brittle part of your app, as it is the most likely part to change.

这也很难让业务逻辑正确的在你看来，由于必须支持所有不同的视图状态的转换。

It is also very hard to get business logic correct in your view, due to having to support all the various view state transitions.

这是非常知名的，这些天来，你只是没有做到这一点：）

It is extremely well known these days that you just don't do this :)

库

这里的问题是抽象的维护和纯度之一。违反这可以迷惑人，让你的应用程序很难维护。

The issue here is one of maintenance and purity of abstraction. Violating this can confuse people and make your app hard to maintain.

从监管局文章对Repository模式在P ：

一个仓库领域和数据映射层之间的中间，像个内存中的域对象集合

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection

一个库是$ P $的抽象psents您的数据存储作为的的集合持有的域对象。

A repository is an abstraction that presents your data storage as a collection that holds domain objects.

没有域的逻辑应该存在于它。相反，它应该在你的域对象存在（顾名思义，因为你的业务逻辑的是的您的域名）。

No domain logic should reside in it. Instead, it should exist in your domain objects (by definition, as your business logic is your domain).

如果不这样做（让你的资料库完成双重任务，也验证域逻辑），将违反SRP的（单一职责原则），并且将是code气味。

To do otherwise (to make your repository do double duty and also validate domain logic) would be a violation of SRP (Single Responsibility Principle), and would be a code smell.

可以具有与域对象的集合，以验证域逻辑（如对象，大小限制等的集合中的依赖）工作更高级别的域对象。他们仍然会使用你的资源库在幕后做的领域对象最终存储/检索，所以他们不会做双重职责（所以不会违反SRP）。

You can have higher level domain objects that work with collections of domain objects to validate domain logic (such as dependencies within a collection of objects, size limits, etc). They will still use your repositories under the covers to do final storage/retrieval of domain objects, so they won't be doing double duty (so won't violate SRP).

控制器

该控制器也并不是一个好地方，把业务逻辑。控制器的工作是在控制器与模型之间进行调解。

The controller is also not a good place to put business logic. The controller's job is to mediate between the controller and the model.

该模型的域，域是您的业务逻辑。

The model is the domain, and the domain is your business logic.

实体

您可能会考虑把域数据的实体。

You might consider putting domain data in entities.

但访问的导航属性时，如果实体连接，你可以触发意外的数据库查询或异常（取决于如果您的上下文被处置，或者没有），你一定要小心。拆卸起来也有问题，因为它会破坏你的对象图，除非你明确地从上下文分离后，它们重新连接对象彼此。

But you must be careful when accessing navigation properties if the entities are attached, as you can trigger inadvertent DB queries or exceptions (depending on if your context is disposed or not). Detaching them is also a problem, as it destroys your object graph unless you explicitly reattach the objects to each other after detaching them from the context.

如果你做单独的域模型类，你可以考虑治疗实体的DTO仅的。

If you make separate domain model classes, you might consider treating entities as DTOs only.

编辑：IValidatableObject

我发现刚才关于实体框架4.1的功能，你可能想看看：在 IValidatableObject 接口

I found out just now about a feature in Entity Framework 4.1 that you may want to check out: the IValidatableObject interface.

您可以让您的实体部分类，并在部分类，实现这个接口。当你这样做时，实体框架将调用验证上的保存，可以调用验证时，它让你感觉这样做。

You can make your entities partial classes, and in the partial class, implement this interface. When you do, the Entity Framework will call Validate on save, and you can call Validate whenever it makes sense for you to do so.

这可能会帮助您避免额外的情况下，您的域模型分割你的持久性模型。

This might help you avoid splitting your persistence model from your domain model in additional cases.

请参阅这篇文章：http://msdn.microsoft.com/en-us/data/gg193959

边注：查看/视图模型

如果你正在考虑这个问题，我建议你避免实体传递回视图的诱惑。它将在很多情况下，打破（例如Javascript的序列化存储视图状态），并导致其他意外情况的数据库查询。回传简单的类型，而不是（字符串，整数，列表，hashsets，字典等），或构建视图模型类传递给视图。

In case you are thinking about it, I suggest you avoid the temptation to pass entities back to the view. It will break in a lot of cases (e.g. Javascript serialization to store view state), and cause unintentional DB queries in other cases. Pass back simple types instead (strings, ints, lists, hashsets, dictionaries, etc), or construct view model classes to pass to the view.