在 Django 中,建议的软件架构是将所有业务逻辑和数据访问放在模型中。
但是,一些同事建议数据访问层应该与业务逻辑(业务服务层)分开。他们的理由是,如果使用不同的数据源,数据访问层可以隔离更改。他们还表示,业务逻辑可以存在于多个模型中。
但是,当我开始使用单独的数据访问层和业务逻辑层进行编码时,数据访问层很简单(基本上是定义数据库模式的模型代码),并且它似乎没有增加太多价值。
将数据访问与 django 模型分离真的有价值吗?或者 django 是否已经通过其 ORM 提供了足够的数据访问层?
我正在寻找已经实现了大量 django 应用程序的开发人员,并了解他们的意见。这适用于中小型网络应用程序。
经过三年的 Django 开发,我学到了以下内容。
ORM 是访问层。不需要更多了。
50% 的业务逻辑都在模型中。其中一些在表格中被重复或放大。
20% 的业务逻辑位于表单中。例如,所有数据验证都在表单中。在某些情况下,表格会将一般领域(模型中允许的)缩小到特定于问题、业务或行业的某个子集。
20% 的业务逻辑最终出现在应用程序的其他模块中。这些模块位于模型和表单之上,但位于视图功能、RESTful Web 服务和命令行应用程序之下。
10% 的业务逻辑最终出现在使用管理命令界面的命令行应用程序中。这是文件加载、提取和随机批量更改。
视图函数和 RESTful Web 服务几乎不执行任何操作,这一点非常重要。他们尽可能地使用模型、表单和其他模块。视图函数和 RESTful Web 服务仅限于处理变幻莫测的 HTTP 和各种数据格式(JSON、HTML、XML、YAML 等)。
尝试发明另一个访问层是一项零价值的活动。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)