Django newbie在模型和可重用业务逻辑方面遇到困难

Question

我是一名.NET开发人员，曾经使用过ASP.NET mvc框架，我试图将自己介绍给python世界，特别是尝试使用django编写一些网站，但我很难弄清楚django的结构。

在ASP.NET mvc中，我使用ASP.NET mvc框架作为一个表示层，我的业务逻辑层和我的数据层是独立的。这是我所有ASP.NET mvc站点的基本结构：

网站是一个ASP.NET mvc项目，而业务逻辑和数据类型项目是类库。在业务逻辑项目中，我使用了一个实体框架模型（带有它生成的所有类），并创建了一些我称之为“Managers”的类，这些类包含了系统的核心逻辑。例如，如果webiste是用于博客网站的，则“usersmgr”将包含以下操作“registerUser,GetUser,confirmUserAccount”，而“postsmgr”将包含操作“addpost,RemovePost,EditPost,AddComentToPost,etc”。

这种方法的思想是，网站只是一个表示层，它使用业务逻辑，但并不与之紧密耦合。我通常会添加一个“管理控制台”（管理员的另一个ASP.NET mvc网站）、“某个合作伙伴的报告”（例如，假设博客有广告，我们给合作伙伴一个登录，这样他们就可以更新广告并查看广告显示次数的报告等）、一个“rest API”，这样如果我想创建一个移动应用程序，我就可以通过rest API公开业务逻辑、运行维护任务的cron或在每天结束时发送电子邮件的报告等。

在我的使用以前架构的.NET项目中，添加这些新东西如下所示：

基本上，所有这些新添加的项目都是业务逻辑的“消费者”。

我很难弄清楚如何用django实现这样的功能，因为web应用程序似乎与它们的模型紧密耦合，这些模型是db表的映射。那么，如果我以后想在一个非django网站中重用业务逻辑，我应该把它放在哪里呢？

关于django应用程序，我到处都读到，在django应用程序中拆分网站是很好的，但是当通常概念是耦合的时候，你该怎么做。例如，一个博客可能有用户、帖子、评论、标签等。我的问题是所有的东西都链接在一起，帖子属于一个用户，标签和评论链接到一个帖子。你是怎么处理这种关系的？

如果有人能帮助我，我会非常感激，我为我的raspberry pi做了一些python脚本，它看起来是一个很棒的语言，但是我在Django上有一段困难的时间。我一定错过了什么...

谢谢！

Answer 1

视图和模型

模型是数据类型组件的等价物。视图相当于网站部分，通常包含“管理器”将包含的代码。

我假设“业务逻辑”指的是类似“只有满足特定条件的用户才可能对一个帖子进行评论”这样的事情。那么您正确地说直接将其放在视图中是不太好的，因为如果您的用户可以以另一种方式访问系统（例如本地运行的命令行实用程序），那么您需要在那里重复该逻辑。

答案是将业务逻辑添加到模型本身，方法是向模型类添加与经理的“getx”、“gety”等价的自定义函数，并向模型的保存挂钩添加类似“这个用户可以这样做吗”的逻辑。

没有什么可以阻止您在视图和模型之间创建管理器层，例如：

models.py：

class Post(models.Model):
    ...

class Comment(models.Model):
    user = models.ForeignKey(User)
    post = models.ForeignKey(Post)
    text = models.CharField(...)

class PostManager(object):
    @staticmethod
    def getPost(id):
        return Post.object.get(pk=id)

    @staticmethod
    def addComment(post, comment_text, user):
        comment = Comment(post=post, user=user, text=comment_text)
        # check stuff
        comment.save()
    ...

views.py：

def add_comment(request, post_id):
    ...
    PostManager.addComment(post=PostManager.getPost(post_id),
                           user=request.user,
                           request.POST['text'])
    ...

但这有几个缺点：

• 模型实例的API仍可用于绕过此类检查
• 您失去了模型API的表达能力
• 有点太冗长

在您的示例（博客、帖子、评论、用户）中，您实际上有两个应用程序。一个处理用户（登录/退出、注册、密码重置等），另一个处理博客（张贴、评论等）。

博客应用程序依赖于用户应用程序并不是一件坏事，利用用户应用程序提供的博客应用程序中的现有功能是有意义的。

最后，这允许易于重用（您可能有另一个有用户的项目，但不是一个博客）。