相关疑难解决方法(0)

在Django中,建议的软件架构是将所有业务逻辑和数据访问放在模型中.

但是,一些同事建议数据访问层应该与业务逻辑(业务服务层)分开.他们的理由是,如果使用不同的数据源,数据访问层可以隔离更改.他们还说,存在可以在多个模型中的业务逻辑.

但是,当我使用单独的数据访问和业务逻辑层开始编码时,数据访问层很简单(基本上是定义数据库模式的模型代码),它似乎没有增加太多价值.

从django模型中分离数据访问是否真的有价值,或者django是否已经为其ORM提供了足够的数据访问层？

我正在寻找已经实施了相当数量的django应用程序并了解他们的意见的开发人员.这适用于中小型Web应用程序.

我遇到了几个最近宣布他们计划将他们的实现从Active Record转移到Data Mapper的ORM.我对这个主题的了解非常有限.对于那些了解得更好的人来说,问题是Data Mapper比Active Record更新吗？当Active Record运动开始时它是否存在？两者如何联系在一起？

最后,由于我不是一个数据库人,对这个主题知之甚少,我是否应该遵循正在转向Data Mapper实现的ORM,就像我作为编写软件的人(不是数据人)的内容一样？

不久前我的一个好同事问了这个问题，现在我将自己的答案公开并分享出来，不仅供以后参考，也可以向社区的答案学习。

我想在应用程序中使用某种数据库层。大多数应用程序都使用 ORM，并且可以在那里构建复杂的查询。如果我不想\xe2\x80\x99 不想使用查询生成器并且更喜欢将其封装在函数或类中怎么办？例如代替：

def get(category_id: int) -> HttpResponse:\n    posts = list(\n        Post.objects\n            .filter(category_id=category_id)\n            .filter(deleted_at__isnull=True)\n            .filter(published_at__gte=yesterday)\n    )\n    return HttpResponse(posts)\n

我想做一些类似的事情：

def recent_posts_from_category(category_id: int) -> List[Post]:\n    return list(\n        Post.objects\n            .filter(category_id=category_id)\n            .filter(deleted_at__isnull=True)\n            .filter(published_at__gte=yesterday)\n    )\n\ndef get(category_id: int) -> HttpResponse:\n    posts = recent_posts_from_category(category_id)\n    return HttpResponse(posts)\n

您如何称呼这种方法/模式？你会把代码放在哪里？

创建一个名为的模块或命名空间database听起来太宽泛了。我不想将这些函数放入utils或helpers命名空间，因为它们显然不是实用程序。

这个词Repository用在这里合适吗？我不会封装所有内容（读取和写入），使用 ValueModel 代替 ORM 模型 (ActiveRecord)，其抽象目标是能够在需要时替换 ORM，构建自定义units of work也超出了范围。

但我正在寻找一些 DRY 助手，你知道，以避免搜索整个存储库，以便在我需要稍微改变行为时找到所有类似的用例。避免重复 ORM 调用链。