关于MVC 3中的模式

Question

It is common sense to keep business logic out of controllers. It is also common sense that database access logic should be on a repository, using a repository pattern, as described here: Repository Pattern

However, the repository pattern specifies only very simple low level database operations: Insert, Delete, Update, Select. People advise to keep validation logic out of it too. That is not a problem, since most of the validation can be put inside the model object itself. The problem comes when we need to make some kind of cross-validation, that is, a validation that needs to look on more than one instance of the same model object (for example, ensuring that a name is unique accross all instances of same object) or, even worse, when the validation logic needs to check two or more objects of different types. In this case, we have a real big hole: the business logic cannot be in controller, cannot be in the repository, cannot be in the object model itself (since the logic is not bound only to the object's properties). Where should this logic be? What is the best design pattern for this kind of requirement?

Answer 1

您可以按照以下说明创建服务层： http : //www.asp.net/mvc/tutorials/older-versions/models- (data)/ validating- with-a-service-layer- cs

Answer 2

The problem here is that your design requires the UI to do validation based on business concerns.

The way to accomplish this is to abstract the validation into the business layer. Your business layer may have methods like ValidateUserIsUnique() and then your ui calls into this layer and receives a result, which is then used for validation.

In particular, for client-side validation MVC provides the RemoteValidationAttribute , but this will only do client-side validation. You will also need to do a server-side validation that calls the same (or a similar) function on the server.