python - Django 新手很难使用模型和可重用的业务逻辑

Question

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

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

该网站是一个 asp.net mvc 项目，而业务逻辑和数据类型项目是类库 (dll)。在业务逻辑项目中，我使用 Entity Framework 模型(及其生成的所有类)并创建一些我称之为“管理器”的类，其中包含系统的核心逻辑。例如，如果网站用于博客网站，则“UsersMgr”将包含以下操作“RegisterUser、GetUser、ConfirmUserAccount”，而“PostsMgr”将包含操作“AddPost、RemovePost、EditPost、AddComentToPost 等”。

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

在我使用以前架构的 .net 项目中，添加这些新内容如下所示:

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

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

关于 Django 应用程序，我到处都读到将网站拆分为 Django 应用程序是件好事，但是通常这些概念是耦合的，你如何做到这一点。例如，博客可能有用户、帖子、评论、标签等。我的问题是一切都链接在一起，帖子属于用户，标签和评论链接到帖子。你如何处理这种关系？

如果有人能帮我解决这个问题，我将不胜感激，我为我的树莓派编写了一些 python 脚本，它看起来是一种很棒的语言，但我在使用 django 时遇到了困难。一定有什么我想念的……

谢谢!

Answer 1

View 和模型

模型相当于您的数据类型组件。 View 相当于网站部分，通常包含您的“经理”将包含的代码。

我假设“业务逻辑”是指“只有满足特定条件的用户才能对帖子发表评论”之类的事情。那么你说直接将它放在 View 中的权利并不好，因为如果你的用户可以通过另一种方式访问​​系统(比如本地运行的命令行实用程序)，那么你将需要在那里重复该逻辑。

答案是将业务逻辑添加到模型本身，方法是将自定义函数添加到模型类中，这些函数相当于您的经理的“GetX”、“GetY”，并添加诸如“此用户可以执行此操作吗”之类的内容模型保存 Hook 的逻辑。

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

模型.py:

class Post(models.Model):
    ...

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

经理.py:

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 的表达能力
• 有点过于冗长

主要优势在于您可以无缝地将整个 Django 模型替换为完全不同的 ORM。但如果这不是你可能做的事情，那么我就不会走这条路。

Django 应用

将内容拆分到应用程序中是个好主意。这些应用程序应该按功能线划分，将整个项目所做的不同事情分开。

在您的示例(博客、帖子、评论、用户)中，您实际上有两个应用程序。一个处理用户(登录/注销、注册、密码重置等)，一个处理博客(发帖、评论等)。

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

最终，这允许轻松重用(您可能有另一个有用户的项目，但不是博客)。