|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-04-28
这要根据架构设计的目标来判断，1）如果框架的应用范围很广比如通用架构如.NET Framework, 那就应该只提供基础功能给用户。2）如果框架的应用领域很具体比如工作流什么的，就应该提供比较具体的服务。不过这是相对来的。
|
| 返回顶楼 | |
|
发表时间：2007-04-28
pupi 写道 确实很难把握这个度。
即使是在某一领域，第一种方案也有自己的问题。 比如普通开发人员和架构的设计者之间就会有一道鸿沟。 另外，前面的朋友也提到了，其实架构本身的维护需要更高级的人才。而且这部分人才升值只怕更快。 还有就是这种架构用一段时间，可能就会过时，又需要花大力气重新开发，并且重新培训。 哪有什么过时的技术？ 如果合公司没人会，而且 不能提高效率就不要 架构 如果招到的人都会新的技术，那么转型用的时间与金钱都会少很多。 |
| 返回顶楼 | |
|
发表时间：2007-04-28
底层是一个快速开发的技术架构，
是所用技术的集成封装，例如spring+hibernate+webwork+osworkflow+jbossrule+quartz, 在此之上封装一个业务模型， 以实现业务逻辑快速实现。 技术架构封装应该是越简单越好，避免重复发明轮子，技术的替换代价，学习成本，维护成本也低。 至于业务模型，不知道，发现抽象通用的业务模型是mission impossible, |
| 返回顶楼 | |
|
发表时间：2007-05-19
第一种也不是绝对的导致程序员没有积极性,如果足够的努力,你可以从那个框架学习到很多东西,也可以思考它到底有没有不足的地方.
一句化,进步取决于自己,而不是取决于你在一个什么样的公司. 个人感觉第一种情况对程序员,对公司都更好. 软件不是个人单打独斗,而是一个工程,如果能够学习到更多的工程思想,对自己的成长更加的有利. |
| 返回顶楼 | |
|
发表时间：2007-05-24
引用 软件不是个人单打独斗,而是一个工程,如果能够学习到更多的工程思想,对自己的成长更加的有利  这句话我到最近才有深刻的体会
|
| 返回顶楼 | |
