锁定老帖子 主题:帮你少写点code
精华帖 (0) :: 良好帖 (0) :: 新手帖 (12) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-02-28
最后修改:2009-03-07
公司是做erp软件的
以前用的是基于ejb2.0架构的,虽然从前(jsp、js)到后(ejb,crud)都有良好的接口,但做一个逻辑操作仍然很复杂。 又平时兴趣积累做出些东东,尝试着去应用到实际开发中去。总结了下这样的东东应该是这样的
1.尽量少的java scriptlet,尽量少的javascript,尽量少的硬sql(既跟着需求常变的)在java源码中 2.常用的逻辑操作流程定义明确,比如crud的开发,应该是step1->step2->step3... 3.基于一个灵活的架构,一些常用的功能尽量提供好,比如i18n,log,transactions,configurable,exception control,auth related等等 4.多定义,少编程。重复性的业务流程尽量模块化,最好达到修改或添加***时候能够改改配置就完成了 5.良好的命名合适和文件目录结构
因为好多操作都是crud操作,故我尝试着以以下方案解决上述问题——=》
1.选个好框架jquery/zk + freemarker + spring mvc + crud data server/dao + spring jdbc template + hibernate dialect,其中的crud的数据抽象和流程(page -> action -> service -> dao)自己要做的。
2.尽量多定义好目录结构 java源文件等就不说了,包命名,类命名,我喜欢springside风格的
war目录 crud crud的html相关文件(js,images,css,。。。 frame frame的html。。。 error pages 404/500。。。
web-inf目录 classes lib tld ftl zul config i18n model(这个是我定义的用于对数据库的数据抽象描述的,类似于**mapping) spring config files * n web.xml
3. 额外的***
i18n我没用spring带的,我自己写一个interceptor加个cache功能,唯一比spring的多一点就是递归遍历文件夹,根据locale和业务相关(prefix)动态加载。这样i18n里的文件应该是这样的 i18n/pur/cn_account.properties
所谓配置,和i18n一样,只不过在interceptor的prehandle里也加载了,这样在action里面就不用出现汉字了,可能没这个必要。。。。
3. 权限相关 filter 做 url 访问判断,可以定义到db里去,**rbac,来个视图就搞定了 model filter 判断,至于model是什么,下面有讲
4. model???
先主要列几个java文件 CrudAction CrudService CrudDAO CrudModel SQLGenerator Dialect ValueFomatter,这下你大概知道偶想做什么了吧,还不明白?那就多列几个
XmlConvertable Field Row TableHeader TableLayer PaginationWrapper OptModel ConstraintModel,这下你大概知道偶想做什么了吧,还不明白?
那我也没办法了,那我就把Field.java放到附件里,感兴趣的看下吧
5.流程 其实呢,简单点理解,这个东东能做什么呢?它主要能做两方面的事情
pluginable功能组织结构通过定义展示给用户 比如用户 kerry 通过权限判断,他可以操作(pur模块下的***,srm下面的***),当然页面和数据你自己定义,象我预设的就是user usergroup role application-module resource这么几层,之间为多多对应
自动crud流程,通过4你应该猜到了一下 js+freemarker by ajax/get/post crudaction(spring mvc annotation多好用啊) listAll listByQuery listInPage addForm/addPost updateForm/updatePost delete
addBatch/addBatchPost deleteBatch importFromExcel/exportToExcel ... 当然了,对httprequest的模块化操作,肯定要封装下了。
在action里,从user(request)里得到的是model, 对model的操作呢?外加点权限的 判断,比如这个model(对应一个视图、表或者**)是否可以导出啊,是否可以删除啊 等等。
crudservice 这一层和action其实几乎是一一对应的,只不过声明了事务处理啊,判断下key constraint啊,对model的**(比如视图的view sql)根据登录user进行下转换啊什么 的——sql转换我深有感触,处处都有啊(比如一个插入,出来key constraint以外, 说不定还有业务上的constraint,这些动态sql都要转换的)
cruddao 这一层比较bug,不过操作起来逻辑上很清晰,无非是crud,至于sql怎么生成的,jdbc template用到的object[]是如何生成的,交给别的类吧
6.说了这么多,关键的一点就是,不要以为上面的代码都要自己去写,no——我按照这个思路做出来个雏形暂时可以达到根据几个xml就可以做action里定义的所有方法了
如果你要问,咦?那页面哪有啊——自动生成啊,反正你把数据库表的每个字段都映射定义了,生成个table/form还有问题啊,切,包括js验证都有了——顺便白一句,我估计,我自己定义的field的属性,应该比jpa的annotation定义的都多…………不过带来的是xml维护的地狱,幸好偶命名的规范些,要不然,一个系统就这几百个xml文件,一行java没有,你上哪去搞去啊
今天晚了,改天看看要不要再写点。 大家来拍砖啊,提点建议最好——毕竟偶是闭门造车啊 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-03-05
借楼主的宝地发表一个最近一直困扰我的问题:
我们用的是BS结构的MVC开发模式,“业务层+Dao层”的模式,某个模块的一个httpRequest过来就把请求定位到该模块的业务层,然后调DAO层操作数据,然后处理结果返回给浏览器端。 这样有一个问题出现了,当模块逐渐增多的时候,我们的业务、Dao操作就会出现一些重复,或者说是相类似的情况,那么作为整个系统来说,这些是可以通过改善设计而瘦身的,可是到目前为止我还没有找到一个比较好的解决方法?希望各位同仁能说说你们是怎么面对这个问题的,谢谢。 |
|
返回顶楼 | |
发表时间:2009-03-05
danni505 写道 借楼主的宝地发表一个最近一直困扰我的问题: 我们用的是BS结构的MVC开发模式,“业务层+Dao层”的模式,某个模块的一个httpRequest过来就把请求定位到该模块的业务层,然后调DAO层操作数据,然后处理结果返回给浏览器端。 这样有一个问题出现了,当模块逐渐增多的时候,我们的业务、Dao操作就会出现一些重复,或者说是相类似的情况,那么作为整个系统来说,这些是可以通过改善设计而瘦身的,可是到目前为止我还没有找到一个比较好的解决方法?希望各位同仁能说说你们是怎么面对这个问题的,谢谢。 1、不断的重构,将类似的结构和通用的方法适度的抽象出来, 成为基础技术架构的一部分, 2、不断的解耦,将系统结构话,横向分层,纵向分模块,提示提取一些常用业务模块, 形成一个稳定、适度的核心业务框架。作为以后类似项目开发的起点和公司的技术资产。 |
|
返回顶楼 | |
发表时间:2009-08-08
danni505 写道 借楼主的宝地发表一个最近一直困扰我的问题:
我们用的是BS结构的MVC开发模式,“业务层+Dao层”的模式,某个模块的一个httpRequest过来就把请求定位到该模块的业务层,然后调DAO层操作数据,然后处理结果返回给浏览器端。 这样有一个问题出现了,当模块逐渐增多的时候,我们的业务、Dao操作就会出现一些重复,或者说是相类似的情况,那么作为整个系统来说,这些是可以通过改善设计而瘦身的,可是到目前为止我还没有找到一个比较好的解决方法?希望各位同仁能说说你们是怎么面对这个问题的,谢谢。 使用泛型可以解决这个问题,增加模块必要增加实体 entity,对于业务逻辑类似的模块,可以做个common service跟common dao,2者都试用泛型。common service 调用common dao,你的新业务逻辑继承common service。这样你就能少些很多代码,业务逻辑发生变化修改也方便。 其实这跟楼主说的抽象出CRUD service和CRUD dao的想法是一样的,少写代码. |
|
返回顶楼 | |
发表时间:2009-08-08
哦,这个项目,我整理了下,暂时小发布了
可以看我最新的博客 “又发明个轮子“。。。。 |
|
返回顶楼 | |
发表时间:2009-08-11
kimmking 写道 danni505 写道 借楼主的宝地发表一个最近一直困扰我的问题:
我们用的是BS结构的MVC开发模式,“业务层+Dao层”的模式,某个模块的一个httpRequest过来就把请求定位到该模块的业务层,然后调DAO层操作数据,然后处理结果返回给浏览器端。 这样有一个问题出现了,当模块逐渐增多的时候,我们的业务、Dao操作就会出现一些重复,或者说是相类似的情况,那么作为整个系统来说,这些是可以通过改善设计而瘦身的,可是到目前为止我还没有找到一个比较好的解决方法?希望各位同仁能说说你们是怎么面对这个问题的,谢谢。 1、不断的重构,将类似的结构和通用的方法适度的抽象出来, 成为基础技术架构的一部分, 2、不断的解耦,将系统结构话,横向分层,纵向分模块,提示提取一些常用业务模块, 形成一个稳定、适度的核心业务框架。作为以后类似项目开发的起点和公司的技术资产。 恢常同意. |
|
返回顶楼 | |
浏览 3118 次