我们都知道,开发业务项目离不开数据库操作组件的使用,数据库是绝大部分业务项目的核心,这也是"CRUD工程师"戏称的由来。业务项目在进行数据库操作时,比较low的方式是直接Open/New
然后各种SQL
字符串操作一把梭。稍微正常一点的项目可能会考虑物色或者自己封装一层ORM抽象,提高CRUD效率,降低数据操作风险。再严谨一点的项目可能会在项目工程管理上考虑下,再进一步增加DAO/DTO/VO
之类的设计模式和概念。
成都创新互联专注于企业全网营销推广、网站重做改版、薛城网站定制设计、自适应品牌网站建设、H5响应式网站、购物商城网站建设、集团公司官网建设、外贸网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为薛城等各大城市提供网站开发制作服务。
信息时代,数据是十分重要的,数据操作是十分敏感的,因此GOFrame
框架对于数据操作管理的工程化思路是严谨的。我们提供了必要的ORM抽象、必要的DAO封装、必要的工程化规范约束。同时,我们并不会采用八股文设计,而是依旧保持简便、灵活、易扩展的工程设计思路。
在一些严谨的业务项目中,已经有了ORM&DAO
抽象、并且项目已有初步工程化设计的前提,依旧存在以下常见的痛点。
当在代码中手动维护数据集合对应的数据结构时,这个坑就算挖好了,就看后面谁掉进去了。
混淆了数据模型与业务的职责,并将数据模型与业务逻辑、接口定义形成了耦合,耦合越大,相关方法、接口维护的成本越高,对数据模型改动产生的风险也越大。常见痛点:
您是否有一种感觉,只要是数据操作,都有理由往DAO
里面丢?
您有可能认为这么做是对的,但是不明确的数据结构都意味着成本和风险。任何的操作,都应当能够明确输入/输出,否则都是不严谨的,对待数据的操作尤其应当严谨。
数据的操作权限应当尽可能收口,如果过于开放那么当业务及人员复杂之后,项目的维护成本和风险都会曲线增加。
常见的问题,是设计一个大的结构体,例如数据模型(更有甚者,将属性全部设计为指针或者interface{}
),从顶层业务到底层数据操作层层透传,方法逻辑根据是否输入特定的属性来判断传参。会造成什么问题呢:
service
层的方法)通过工具自动化实现数据集合到数据模型的代码生成,避免人工维护造成的不同步。
将数据模型通过entity
包维护,业务模型通过model
包维护,通过不同的包职责来做区分。数据模型由工具化维护,业务模型根据业务场景由开发者定义和维护。
通过工具自动化实现数据集合的DAO
代码生成,提高生产效率。DAO
中只有自动化生成的基础数据操作,不封装特定业务逻辑。
避免数据模型直接被当做DAO
参数使用,避免踩坑。GoFrame
框架引入了DO
包,在DAO
操作时自动化转换为数据集合对应的数据结构,提高DAO
操作的效率,降低操作风险。
由于数据操作已经由DAO
包进行了统一维护,通过将DAO
包迁移到了Service
层的internal
目录下,实现项目工程下仅仅只有Service
层的代码可以通过DAO
执行数据操作。
名称栏目:创新互联GoFrame教程:GoFrameDAO对象封装设计-工程封装设计
文章位置:http://www.mswzjz.cn/qtweb/news15/155465.html
攀枝花网站建设、攀枝花网站运维推广公司-贝锐智能,是专注品牌与效果的网络营销公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 贝锐智能