|
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-12-11
本人也来发表两句。看了搂主和各位高手以及菜鸟们的精彩讨论，晚辈真是受益非浅。
看得出搂主也是出于无奈，各方面的因素迫使搂主使用了这样一个架构。 引用 我所说的框架，我觉得确实会对他们有很深的误导，但现在的目标就是快速出成果啊。
我觉得要看情况的，一个开发团队如果超过5人(不包括美工)那已经是非常可怕的，交流成本过高，模块也难分，而且具搂主说一半都是新手。。。。。那确实楼主的架构或者说是方法应该是“快速出成果”的最好方法。如果5个人的团队，大家都是由点经验的，那楼主这个想法真不怎么样。 引用 你说的培训，那不是我决定的，我只是一个developer，公司大，制度就那样，我也很无奈。
确实搂主所处环境恶劣，同情。 引用 像你说的这种情况，一个公司这么多新手，我觉得还是公司管理有问题，要不为什么就留不住人呢？
显然是留不住人嘛，就这种开发团队，新手翅膀硬了不走才怪。 引用 外包，可能有时候关键得看完成的速度，其它的有时候就不重要了，再说了，对日外包有些东西也不值得去弄得那么优雅，只要不给自己找麻烦，按时交工就行了。不过就是感觉有点苦了刚去的小兵们，不过有时候也是没办法的，很多去工作的小兵都是为了去混口饭吃，没那么多理想，呵呵~
100个赞同阿。每个人的想法都不一样嘛，何必强求人家要 O O 呢。 而且搂主做的是报表系统，报表系统本来就是sql嘛，毕竟对象数据库还不成熟，Hibernate说实话做报表也不怎么方便啊。做一个sql生成器有啥不可以呢。 |
| 返回顶楼 | |
|
发表时间：2006-12-11
比较同意楼主，OO不是教条，框架是用来解决问题的，楼主的框架也只是MVC的一种实现而已，并没有说这是标准，简单是硬道理!
|
| 返回顶楼 | |
|
发表时间：2006-12-12
真理往往掌握在小数人手中，就像十六世纪前有人说“地球是圆的”会被人笑掉大牙一样，更甚者丢掉性命。
我觉得楼主很勇敢，在“权威”面前说了很自己想法，也许事情根本就没有所谓的“答案”。 是先有了问题才有了技术，所谓的OO也是总结前人的经验抽象理论化出来的，OO可以解决问题，楼主的方式也同样可以解决问题（楼主没说过他的是OO），虽然这种方式看起来违背了千百万人死守的神圣教条,但它却是人类去思考去突破的一种表现，而这种表现就是人类进步的源泉。 小弟不才，有说错的地方请纠正。还有请robin原谅我说了一些和技术无关的东西,该删就删了吧。 |
| 返回顶楼 | |
|
发表时间：2006-12-12
giscat 写道 mvc,用map充当model的的确是一个简捷高效的方式，
许多框架的model就是一个map或增强了的map 没有任何一个通用的框架可以提供model，model永远需要开发者根据自己的业务情况去开发。model的来源是业务需求，与技术无关。 如果一个框架提供了model，他就不是一个通用的框架了，而是一个关于某个业务领域的开发平台，例如SAP和工作流引擎。 通用的框架中不可能提供业务层，框架的任务就是为业务层去创造一个良好的条件。struts创造的条件是：业务层可以摆脱UI过程的影响；spring创造的条件是：业务层可以摆脱物理分布的影响；lz的框架创造的条件是：给了业务层一个数据库连接，并且业务层必须在sql中实现。 lz似乎认为OOP、领域模型这些东西必然和高成本、复杂、大型、>=3年工作经验、以及一大堆乱七八糟的类联系在一起。这也难怪，很多蹩脚的设计就是这样的，并且号称OOP、可扩充、灵活、高性能、易于维护，事实上一样都沾不上边。有这么多教训摆在眼前，很多人宁愿相信quick and dirty，也不相信OOP了。 |
| 返回顶楼 | |
|
发表时间：2006-12-12
与LZ的思路一致，自己实现的一个超级简单的MVC框架ajf(agile java framework)
http://www.javaresearch.org/article/58413.htm 现丑了 |
| 返回顶楼 | |
|
发表时间：2006-12-12
直接jsp里面放sql岂不更简单，更适合你的团队，更符合你的逻辑？
|
| 返回顶楼 | |
|
发表时间：2006-12-12
楼主继续努力,只要善于学习钻研,前途未可限量.
BTW:有空看看Banq的文章. |
| 返回顶楼 | |
|
发表时间：2006-12-12
这是我把代码贴出来后，开的一个帖子
http://zwchen.iteye.com/admin/show/38774 大家可以下载代码看看，我觉得还是很有参考意义的。 看代码前，建议先看我原来写的两篇文章： http://zwchen.iteye.com/admin/show/38277 （理论篇） http://zwchen.iteye.com/admin/show/38278 （实现篇） 本文是第三篇：代码篇。欢迎大家给出公正的评价，以及待改进的地方。 |
| 返回顶楼 | |
|
发表时间：2006-12-13
希望楼主坚持独立思考精神。顶一下。楼主思考的方向是正确的。基于Map的实现，不够完备，但是作为迭代过程的初始解，也是很自然的选择。只要坚持探索，就能找出满意的解。
在我看来，许多流行的Domain Model和ORM的方案，都是丑陋不堪的。很简单的项目，硬是制造出几十，几百的XO （PO，VO， DTO， DAO， ...）。打开文件一看，大多是空的。就像一具具没有血肉，没有灵魂的骷髅。看着那样的东西，我马上就会联想到一个词-作茧自缚。所以一段时间以来，我一直想写一篇文章，介绍一个替代的选择。但是至今没有想好如何着笔，主要是形而上的部分拿不定主意。如果楼主或其他人有兴趣，我可以另开一贴，直接进人主题和数据结构。 我的方案是我前几年做项目的过程中提炼出来的。我们的项目是一个类似MS BizTalk或BEA Integration Server的项目。我们实现的是一个引擎，下游的团队用它来开发他们的项目。随着下游项目的加入，Domain Model就要修改，平均一个月改一次。所以项目的性质决定了它必须是动态的开放的。几年的实践证明了：Java也可以有"弱类型"，Java也可以是动态的，Java也可以很简洁，就看你自己怎么做。ROR的崛起，也从另一个方面证明了, 对多数项目而言， Wrapping is much better than Mapping。 |
| 返回顶楼 | |
|
发表时间：2006-12-13
只要重构!重构!再重构!
你的框架会越来越好用... 我以前的公司开发的框架中开发一个流程非常的快... 但是里面的代码不论早晚都是像流体一样把握不住 想加点功能....难比登天.... |
| 返回顶楼 | |
