Django 和领域层

发布于 2024-10-04 09:41:18 字数 158 浏览 0 评论 0原文

如何使用 django 组织我的域层？

我知道我可以编写自定义管理器来保存我的查询，但是如果我想要更灵活的东西（例如规范模式）怎么办？

是否有 Django 特有的域模式？

我目前正在设计一个使用 Django 的大型应用程序，我想知道如何正确完成域层。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

苏佲洛 2024-10-11 09:41:18

这个问题有点主观，但我的两点意见是：

同时更改多个对象的业务逻辑通常应该放在管理器中。
创建对象的特殊逻辑应该位于管理器中，认为MyModel.objects.create_complex(foo, bar)
用于计算自定义信息、更新某些复杂字段等的业务逻辑应该位于方法中（或在您的模型上，请考虑 my_instance.get_accumulated_interest()。这些不应该保存模型，只更新一些字段然后返回。
用于验证信息的业务逻辑应该放入模型的 clean 方法中，或者作为特殊形式的 clean 方法。如果它位于模型上，则可以更轻松地从系统的不同部分重用它。
一般来说，如果你找不到地方放置有意义的逻辑，我会将它们放在视图中。
离线处理应该进入自定义管理命令，并且您应该能够使用相同的参数多次重新运行相同的命令，而不会产生任何不需要的效果。

当我说“应该进入 X”时，我的意思是系统的这些部分应该调用您自己的模块，这些模块可能与 Django 完全分开。这可以使单独测试这些功能变得更容易。

编辑：

对于“规范模式”，我建议编写一个更高级别的模块来调用管理器方法来过滤对象。使用 Q 对象，您可以可以创建通用过滤器，您可以像这样使用：

q = Q(field__isnull = False) | Q(otherfield__isnull = False)
objects = Model.objects.filter(q)

编辑 II：

我突然想到：Python 允许非常通用的编程。类和函数是一等公民。考虑下面的例子：

def HasFooBar(model_class):
    return list(model_class.objects.filter(somefield__contains = 'foobar'))

def BarHasBaz(model_class, arg):
    return list(model_class.objects.filter(somefield = arg))

objects = HasFooBar(MyModel) + BarHasBaz(OtherModel, baz)

你看到我刚才做了什么吗？ :)

This question is a bit subjective, but here are my two cents:

Business logic for changing multiple objects at the same time should in general go in a manager.
Special logic for creating an object should be in the manager, think MyModel.objects.create_complex(foo, bar)
Business logic for calculating custom info, updating some complex field, etc, should be in methods (or properties) on your models, think my_instance.get_accumulated_interest(). These should not save the model, only update some fields and then return.
Business logic for validating information should either go in clean methods on the model or as clean methods in special forms. If it is on the model it can be reused from different parts of the system more easily.
In general, if you cannot find a place to put the logic that makes sense, I put them in the views.
Offline processing should go in custom management commands and you should be able to rerun the same command with the same arguments multiple times without any unwanted effects.

When I say "should go in X", I mean that these parts of the system should call into your own modules that may be separate from Django alltogether. This may make it easier to test these functions in isolation.

Edit:

For the "specification pattern" I would suggest writing a higher-level module that calls manager methods to filter objects. With Q objectsyou can create generic filters that you can use like this:

q = Q(field__isnull = False) | Q(otherfield__isnull = False)
objects = Model.objects.filter(q)

Edit II:

It just struck me: Python allows very generic programming. Classes and functions are first-class citizens. Consider the following example:

def HasFooBar(model_class):
    return list(model_class.objects.filter(somefield__contains = 'foobar'))

def BarHasBaz(model_class, arg):
    return list(model_class.objects.filter(somefield = arg))

objects = HasFooBar(MyModel) + BarHasBaz(OtherModel, baz)

You see what I just did there? :)

回复收藏 0 原文

~没有更多了~