Tai*_*Tea 15 django design-patterns business-logic-layer data-access-layer django-models
在Django中,建议的软件架构是将所有业务逻辑和数据访问放在模型中.
但是,一些同事建议数据访问层应该与业务逻辑(业务服务层)分开.他们的理由是,如果使用不同的数据源,数据访问层可以隔离更改.他们还说,存在可以在多个模型中的业务逻辑.
但是,当我使用单独的数据访问和业务逻辑层开始编码时,数据访问层很简单(基本上是定义数据库模式的模型代码),它似乎没有增加太多价值.
从django模型中分离数据访问是否真的有价值,或者django是否已经为其ORM提供了足够的数据访问层？
我正在寻找已经实施了相当数量的django应用程序并了解他们的意见的开发人员.这适用于中小型Web应用程序.
S.L*_*ott 25
经过三年的Django开发,我学到了以下内容.
ORM是访问层.不需要更多.
50%的业务逻辑都在模型中.其中一些在表格中重复或放大.
20%的业务逻辑采用Forms.例如,所有数据验证都在表格中.在某些情况下,表单会将一般域(在模型中允许)缩小到某个特定于问题,业务或行业的子集.
20%的业务逻辑在应用程序的其他模块中结束.这些模块位于模型和表单之上,但在视图函数,RESTful Web服务和命令行应用程序之下.
使用管理命令界面,10%的业务逻辑在命令行应用程序中结束.这是文件加载,提取和随机批量更改.
视图功能和RESTful Web服务几乎不做任何事情是非常重要的.他们尽可能使用模型,表单和其他模块.视图函数和RESTful Web服务仅限于处理HTTP的变幻莫测和各种数据格式(JSON,HTML,XML,YAML等).
试图发明另一种接入层是零价值的练习.
| 归档时间： |
|
| 查看次数： |
4928 次 |
| 最近记录： |