0

C# ASP .NET MVC 4.0

我了解 MVC 模式，但是当涉及到模型时：

public class User
{
    int id { get; set }
    int name { get; set; }
}

我可以看到将业务逻辑与存储库（数据获取器）分开的好处。就像是：

public class UserRepository
{
    IEnumerableList<User> GetAllUsers()
    {
        IEnumerableList<Product> users = //LINQ or entity;
        return IEnumerableList<Product> users;  
    }  

    int GetScoreByUserId( id )          
    {
        int score = //LINQ or entity;
        return score;  
    }  
}

业务逻辑是否会进入 User 类，例如：

public class User
{
    public int id { get; set }
    public int name { get; set; }

    public bool HasDiscount( int id )
    {
        if( GetScoreByUserId( id ) > 5 )
            return true;
        return false;
    }
}

有没有人有一个像样的例子。对我来说，找到这样一个明确的例子并不像 1 2 3 那样容易。

上面的代码看起来没问题吗？存储库应该扩展用户还是应该是一个单独的类......或者所有这些东西都应该放在用户类本身中吗？

编辑::---- 所以是这样的吗？

public class UserBusinessLogic
{
    public bool HasDiscount( int id )
    {
        if( GetScoreByUserId( id ) > 5 )
            return true;
    }
}

编辑::---- 澄清我现在如何理解这一点

在此处输入图像描述

4

2 回答 2

3

根据您的情况，有几种选择。例如，它们在 Martin Fowler 的“企业应用程序架构模式”一书中进行了描述。因此，这取决于您要选择的架构模式。

当你试图找到一个解决方案时，你实际上是在制作类似于域模型模式的东西（用于相关业务逻辑的用户类和用于数据访问的单独 UserRepository 类）。

您还可以将这些职责合并到一个类 User 中（业务逻辑和数据访问），因此您将进入 Active Record 模式。

然而，每种模式都有其优点和缺点，我认为使用域模型肯定会更好，因为它会导致 OOP 和正确的关注点分离。

于 2013-07-17T13:01:25.747 回答
1

我按照这种模式取得了巨大的成功：FooController -> FooTasks -> FooRepository。

这个聪明的家伙向我展示了这一点。

“控制器将模型提供给 FooTasks，后者又将模型转换为进入 FooRepository 的业务对象。好处是任何类型的数据的低级表示都很好地隐藏在控制器之外。控制器应该不需要知道数据在持久化时的样子。”

它极大地帮助了我的 MVC 应用程序。

于 2013-07-17T13:06:26.687 回答