向ASP> NET MVC 3 C＃中的存储库添加简单的业务逻辑

Question

I have a question concerning an issue that has already been disputed many times in stackoverflow (I apologize for this) but no general answer has ever been given because of the subjectivity of the topic from one case to another: can we add business logic to the repository layer according to the repository pattern? I have an MVC 3 application with ViewModels (that means I don't use the ViewData at all). The model is an LinqtoSQL EF of course connected to a database. Currently I am accessing the entities directly from the controllers which contain all the business logic and I wrap the data needed for the Views in specific ViewModels. Now I am starting to refactor and I realized that the best way to avoid code duplication, besides optimizing the ViewModels, is to delegate all the queries to a repository, which communicates with the EF, and create tailored methods to be used by the controller. Now, taking into account that I would like the repository to return actual objects and not expressions, I was thinking about delegating small pieces of business logic to the repository in order to make my code clearer. However for the sake of loose coupling, I would like to have your opinion. In the code shown below (which currently resides in the controller) all the variables except lprojectionPercactualValue are taken from the database. Therefore I wanted to move this piece of code to the repository and call a method with signature:

public string getColor (int ItemId, float lprojectionPercactualValue);

The method needs the ItemId in order to retrieve the values specific for that Item. What do you think about this design decision? Is it better to leave the code in the controller, move to another method still in the controller (create a method or even a class dedicated) or move it to the repository as explained?

if (litem.Ascending == true)
{
    if (lprojectionPercactualValue < lminThreshold)
    {
        lcolor = "RED";
    }
    else if (lprojectionPercactualValue > lminThreshold && lprojectionPercactualValue < lmedThreshold)
    {                                   
        lcolor = "YELLOW";
    }
    else //(percValue >= item.Max_Threshold)
    {
        lcolor = "GREEN";
    }
}

else
{
    if (lprojectionPercactualValue > lminThreshold)
    {
        lcolor = "RED";
    }
    else if (lprojectionPercactualValue < lminThreshold && lprojectionPercactualValue > lmedThreshold)
    {
        lcolor = "YELLOW";
    }
    else //(percValue <= item.Max_Threshold)
    {
        lcolor = "GREEN";
    }
}

Answer 1

It is not recommended.

How does Repository now about the lminThreshold ? What if this value itself needs to come from a lookup table or a config file?

Move it to business layer - and if you do not have one, to the controller.

Answer 2

Wrap your EF logic inside a DAL layer that you proxy via a Repository class. This is raw data and since you require additional crunching on it, it is recommanded to have a service layer that uses it and applies your custom business rules over it. The Repository here is meant to discourage any DB code duplication.

At this point, you only check if the lprojectionPercactualValue goes over some treshold, but what if, at some point, you will need to compute that treshold in some fancy manner or you decide to perform some sort of validation or some other thing like that. These are all domain specific decisions and they should reside in a layer of their own.

Answer 3

恕我直言，您最好在控制器和存储库之间添加一个业务层，并将上面的getColor代码放入业务层中（或者根据需要将其分成几种方法），如果在其他控制器中需要它，该怎么办？不再是简单的if / else，如果明天您必须从Web服务获取阈值，您想在控制器或存储库代码中进行所有这些更改吗？