MVC，我明白了，但是分离出存储库功能甚至业务逻辑的模型......最佳实践？答案

【问题标题】：MVC, I get it, but separating out the model for repository functions and maybe even business logic... Best practice?MVC，我明白了，但是分离出存储库功能甚至业务逻辑的模型......最佳实践？
【发布时间】：2013-07-17 12:38:52
【问题描述】：

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 那样容易。

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

EDIT::---- 所以是这样的？

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

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

【问题讨论】：

严格来说，这与“MVC”模式无关。它属于更一般的关注点/业务规则分离。但是您的UserRepository 绝对应该不继承User。
如果是这样，我把它分开了.. 这样分开好吗？（所以请参阅我的编辑）
存储库应处理数据访问。业务逻辑可以放入业务逻辑层/服务层。因此，业务层调用存储库来获取实体，执行它需要执行的操作并将所需的任何内容返回给您的控制器。
你能参考我上次的编辑吗？这是相当典型的布局吗？
@JamesT - 实际上，ASP.NET MVC 所指的“viewmodel”是presentation model 概念（不过，我更喜欢称它为 “presentation object”，因为 Fowler在所有事情上都打“模型”的倾向是F___ING混淆）。这意味着您的“视图模型气泡”应该在视图内。

标签： c# asp.net-mvc model-view-controller separation-of-concerns

【解决方案1】：

根据您的情况有几个选择。例如，Martin Fowler 所著的“企业应用程序体系结构的模式” 等书中对它们进行了描述。所以这取决于你要选择的架构模式。

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

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

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

【讨论】：

啊，所以你说有不同的类型......所以我代表的版本被称为域模型。我参加了 .NET MVC 课程，领域模型方法似乎对我敲响了警钟。如果我是对的，这种分离的优势意味着您可以精确地表示（视图模型）将在视图中显示的内容！如果这是正确的，现在对我来说完全有意义。我的意思是，您为什么要从视图中访问存储库方法？答案是，你不要！

【解决方案2】：

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

It was shown to me by this smart guy.

"控制器将模型交给FooTasks，FooTasks依次翻译将模型转换为进入 FooRepository 的业务对象。这好处是任何类型的较低级别的表示数据很好地隐藏在控制器之外。控制器不应该需要知道数据在持久化时的样子。”

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

【讨论】：