|
锁定老帖子 主题：一个简单架构方案，请大家批评指正，谢谢
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-12-04
fight_bird 写道 别浪费时间，除非你有独创性的技术，或者做个玩具玩玩也可以。
这东西不管能不能称得上框架，一旦你要用到商业项目上，就得考虑更多：可靠性、开发效率、IDE集成、性能瓶颈规避、文档、学习曲线、测试覆盖率、扩展性、框架之上的组件集/特性集、技术成本......，你真能搞定？ 谢谢，现阶段没有考虑这么多，也就是有兴趣、想法，就尝试下看看，我会注意的。 |
| 返回顶楼 | |
|
发表时间：2011-12-04
挺好的，不过的话，还是用框架方便一些，比较喜欢用框架。呵呵。
|
| 返回顶楼 | |
|
发表时间：2011-12-04
合理使用配置
|
| 返回顶楼 | |
|
发表时间：2011-12-05
重复制造轮子。
|
| 返回顶楼 | |
|
发表时间：2011-12-05
对于做很小的稳定的应用，其实什么架构都差不多，没有说好与不好，合适就行了；
但对于有一定规模的，业务庞大的，需要经常维护的应用，这样的架构就不合理了，需要重点说的是，你那个servlet处理太多事情了，这样不好维护的，明明不相关的功能，就应该分开来维护，不应该堆在一起。这就是低耦合的原则。 |
| 返回顶楼 | |
|
发表时间：2011-12-05
chenyinle 写道 对于做很小的稳定的应用，其实什么架构都差不多，没有说好与不好，合适就行了；
但对于有一定规模的，业务庞大的，需要经常维护的应用，这样的架构就不合理了，需要重点说的是，你那个servlet处理太多事情了，这样不好维护的，明明不相关的功能，就应该分开来维护，不应该堆在一起。这就是低耦合的原则。 我理想的servlet统一控制转发，维护放在业务层，目前这个servlet类还有待改进 |
| 返回顶楼 | |
|
发表时间：2011-12-05
changxin 写道 坏孩子 写道 需要有良好的ide支持才能提高工作效率，看上去action可以重用，事实上项目中只有少数的action适合重用，弱化java的作用。我们公司就用这样一个框架
我的想法是统一控制层、数据库层，把工作重点放在业务层。 如果把业务拆成一个个sql，对于很多操作都可以通过配置实现，减少代码量，但也会带来性能的牺牲。我觉得视情况而定，有些也是可以接受的 最后会简化成以存储过程或者sql为主导的开发方式，业务最终被放在了数据库上。 能不能推广，至少我们有几百个应用在用吧，当然是强推的。 至于好不好用，能不能提高开发效率，见仁见智。 |
| 返回顶楼 | |
|
发表时间：2011-12-05
坏孩子 写道 changxin 写道 坏孩子 写道 需要有良好的ide支持才能提高工作效率，看上去action可以重用，事实上项目中只有少数的action适合重用，弱化java的作用。我们公司就用这样一个框架
我的想法是统一控制层、数据库层，把工作重点放在业务层。 如果把业务拆成一个个sql，对于很多操作都可以通过配置实现，减少代码量，但也会带来性能的牺牲。我觉得视情况而定，有些也是可以接受的 最后会简化成以存储过程或者sql为主导的开发方式，业务最终被放在了数据库上。 能不能推广，至少我们有几百个应用在用吧，当然是强推的。 至于好不好用，能不能提高开发效率，见仁见智。 另外看到有人说这个不算框架，我觉得这个类型框架算一个另类吧 |
| 返回顶楼 | |
|
发表时间：2011-12-05
我们公司以前用的就是类似这样的框架，基础的功能服务都可以重用，主要任务就是定义流程，并且数据是放在一个大容器里面，这样的优点是实现起来快，开发人员上手也容易，缺点是很难维护，流程会越来越大。你可以了解一下IBM的WSBCC，现在叫BTT吧。
|
| 返回顶楼 | |
|
发表时间：2011-12-06
changxin 写道 lovexp2010 写道 哈哈，你自己写了一个框架~~，只不过是简单的，适合你的业务
恩，也就一个简单的架子，适合自己而已 支持，比用现成的好 |
| 返回顶楼 | |
