|
最初由 wuxd 发布
[B]个人觉得这样写对于频繁的业务变动的应变性还是有一定的适应性的,如果完全按照MVC的架构开发一套系统,在这样频繁的业务变动下我想很快也会出现部分业务逻辑放在JSP中。因为一般业务变动的要求时间都比较紧,如两个7.1。
另外,对于主要逻辑处理还是放在了BL层了,并且做了最大的公用,比如投、承、批,个人觉得里面还是有很多可学之处的,至少我从中学到了很多,整个流程简单易懂易于维护
以上纯属为个人几年的真实感受 [/B]
这个是两回事情,谁说jsp修改逻辑就快,java bean就慢呢???
最初由 cooltails 发布
[B]维护量就算很大但是维护的费用仍然低廉呀!中科软的人力成本不就是很低吗?人海战术才是王道....... [/B]
这个又是那来的理论呢???
人海战术,最后只会管理失控,系统一团糟。
这个是两回事情,谁说jsp修改逻辑就快,java bean就慢呢??? [/B]
呵呵,我这里好像没有说JSP比JAVABEAN的修改就会快啊,但JSP调试起来还是很方便的,直接刷新就可以
中科软的东西确实很一般,当然也有一点就是一分钱一分货.钱少货就差.
他们招了一堆应界生,做出来的东西问题比较多.
虽然对架构方面不是很了解,不过对这个系统接触了两年多了,感受也是颇深,有理有弊吧.
就像各位所说,由于架构的问题可能不够严谨
不过修改起来还是比较灵活
我也赞同他们招了一批应届生,用这种降低成本的办法来降低价格
同时也带来了无穷的隐患,系统的漏洞千奇百怪
对这些刚毕业的学生的影响也很大,因为整个开发规范性很不够
JSP修改功能是爽阿,很快就能实现,看效果也很容易,不过时间久了,代码多了,后来人维护困难,而要完成任务,增加新功能,于是冗余代码、互相矛盾的代码到处都是,如果对核心部分作改动会发现很痛苦,一不小心就到处引起错误,
而用组件开发,特别是MVC级别的架构开发,代码上手很难一下子理解,要写出一段可以用的代码很是困难,但一旦理解了架构,增加新功能和模块,其实就是拷贝,写一点点业务代码的实现,发现效率会很高,而且代码也容易保持统一,以后就是升级也方便,代码寿命明显增强,健壮性也高。
总体感觉,MVC之类的架构,目的就是统一和重用,代价就是复杂和入门难,构造架构也很关键,需要高手来写。而JSP写的东西,入门简单,很快就能看到效果,代价就是如果要升级系统或者大的改动,一般就是要重写整个系统了。
个人之见,仅供参考。
国内的业务运行模式有什么特殊之处吗?
业务运行模式和mvc架构有什么必然的联系吗?请赐教
ebao,尚阳,优创,燕梭的核心业务系统乃至其他的BS结构的系统不是都是用的MVC 吗。 [/B]
解释不清楚,想了解的随便找个保险公司待一段时间就能了解了。估计10家里面有8家情况差不多
谁有能力care最后的问题!?大家都希望管理严谨一些,最终变成人海战术,说明市场需要。
有时候你不得不佩服中科软在人员流动这么大的情况下,还能保证这么多项目的运转。说明还是有一套自己办法的。 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
|