是或否:MVC 中的模型是否应该包含应用程序逻辑?

问题描述

昨天我与我们的一位开发人员就 MVC 进行了一些讨论，更准确地说是关于模型组件在 MVC 中的作用.

Yesterday I had some discussion with one of our developers regarding MVC, more precisely about the role of the model component in MVC.

在我看来，模型应该只包含属性而几乎没有功能，因此模型类中的方法尽可能少.

In my opinion, a model should just contain properties and almost no functionality so there are as few methods in model classes as possible.

不过，我的同事认为模型可以而且应该具有更多功能，并提供更多功能.

My collegue though believes that models could and should have more than that and offer a lot more functionality.

这是我们争论的一个例子.

Here is an example we argued about.

示例 1

假设我们想创建一个博客.博客有文章和标签.每篇文章可以有多个标签，每个标签可以属于多篇文章.所以我们在这里有一个 m:n 关系.

Let's say we wanted to create a blog. A blog has articles and tags. Each article can have multiple tags and each tag can belong to multiple articles. So we have a m:n relation here.

在伪代码中，它可能看起来像这样:

In pseudocode it'd probably look something like this:

class Article{
    public int id;
    public String title;
    public String content;
    public Tag[] tags;

    // Constructor
    public void Article(id, title, content, tags){
        this.id = id;
        this.title = title;
        this.content = content;
        this.tags = tags;
    }
}

class Tag{
    public int id;
    public String name;

    // Constructor
    public Tag(id, name){
        this.id = id;
        this.name = name;
    }
}

现在，假设我们在这里工作是松耦合的，这意味着我们可能有一个还没有标签的文章实例，所以我们将使用 Ajax 调用(到我们的后端，它有一个包含所有标签的数据库)信息)以获取属于我们文章的标签.

Now, assume that we're working loose coupled here which means that it could happen that we have an instance of Article which has no Tags yet so we'll use an Ajax call (to our backend which has a database containing all the information) to get the tags that belong to our article.

这里是棘手的部分.我相信通过 Ajax+JSON 获取后端数据应该是控制器使用专用类的工作，该类使用解析器处理 ajax 请求:

Here comes the tricky part. I believe that getting the backend data via Ajax+JSON should be the controller's job using a dedicated class which deals with the ajax request using a parser:

class MyController{
    private void whatever(articleID){
        Article article = (Article) ContentParser.get(articleID, ContentType.ARTICLE);
        doSomethingWith(article);
    }
}

public abstract class ContentParser{
    public static Object get(int id, ContentType type){
        String json = AjaxUtil.getContent(id, type.toString()); // Asks the backend to get the article via JSON
        Article article = json2Article(json);

        // Just in case
        Tag[] tags = article.tags;
        if (tags == null || tags.length <= 0){
            json = AjaxUtil.getContent(article.id, ContentType.TAGS); // Gets all tags for this article from backend via ajax
            tags = json2Tags(json);
            article.tags = tags;
        }

        return article;
    }

    // Does funky magic and parses the JSON string. Then creates a new instance of Article
    public static Article json2Article(String json){
        /*
         ...
        */
        return new Article(id, title, content, tags);
    }

    // Does funky magic and parses the JSON string. Then creates a new instance of Tag
    public static Tag[] json2Tags(String json){
        /*
         ...
        */
        return tags;
    }

}

示例 2

我的同事认为这违背了 MVC 的想法，他建议模型应该注意这一点:

My collegue believes that this breaks with the idea of MVC, he suggests that the model should take care about this:

class Blog{
    public int id;
    public String title;
    public Article[] articles;

    // Constructor
    public Blog(id, title, articles){
        this.id = id;
        this.title = title;
        this.articles = articles;
    }

    public void getArticles(){
        if (articles == null || articles.length <= 0){
            String json = AjaxUtil.getContent(id, ContentType.ARTICLE); // Gets all articles for this blog from backend via ajax
            articles = json2Articles(json);
        }
        return articles;
    }

    private Article[] json2Articles(String json){
        /*
         ...
        */
        return articles;
    }

}

class Article{
    public int id;
    public String title;
    public String content;
    public Tag[] tags;

    // Constructor
    public Article(id, title, content, tags){
        this.title = title;
        this.content = content;
        this.tags = tags;
    }

    public Tag[] getTags(){
        if (tags == null || tags.length <= 0){
            String json = AjaxUtil.getContent(id, ContentType.TAGS); // Gets all tags for this article from backend via ajax
            tags = json2Tags;
        }
        return tags;
    }

    // Does funky magic and parses the JSON string. Then creates a new instance of Tag
    private Tag[] json2Tags(String json){
        /*
         ...
        */
        return tags;
    }
}

在模型之外，您可以执行以下操作:blog.getArticles(); 或 article.getTags(); 获取标签，而无需担心 ajax 调用.

And outside of the model you'd do: blog.getArticles(); or article.getTags(); to get the tags without bothering with the ajax call.

然而，尽管这可能很方便，但我相信这种方法与 MVC 不同，因为在一天结束时，所有模型都将充满各种方法，可以做各种时髦的事情，而控制器和助手类几乎什么都不做.

However, as handy as this might be I believe that this approach breaks with MVC because at the end of the day all models will be full of methods that do various funky stuff and the controller and helper classes do almost nothing.

在我对 MVC 的理解中，模型内部应该只包含属性和最少的辅助方法".例如，模型文章"可以提供一个方法 getNumOfTags() 但它不应该自己执行任何 Ajax 调用.

In my understanding of MVC, models should only contain properties and a minimum of "helper methods" inside. For example a model "Article" could offer a method getNumOfTags() but it shouldn't do any Ajax calls on its own.

那么，哪种方法是正确的?

So, which approach is correct?

推荐答案

一般来说，我也尽量让控制器在逻辑方面保持简单.如果需要业务逻辑，它将上升到服务层"类来处理它.这也避免了重复任何代码/逻辑，如果业务逻辑发生变化，最终会使整个项目更易于维护.我只是将模型纯粹作为实体对象.

Generally I try to keep controllers simple in terms of logic too. If business logic is required, it will go up to 'service layer' classes to handle it. This also saves repeating any code/logic too, which ultimately makes the whole project more maintainable if business logic was to change. I just keep models purely as entity objects.

我认为上面的答案很好地总结了它，但很容易根据设计模式对项目进行过度设计:选择适合您且最易于维护/最高效的任何东西.

I think the answer above sums it up nicely though, it is easy to over engineer a project based on design patterns: Go with whatever works for you and is most maintainable/efficient.

这篇关于是或否:MVC 中的模型是否应该包含应用程序逻辑?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！