标签：产生 扩展 c# 接收 创建 员工 离职 method 无法
从学习编程开始到现在已经开发11年了，期间经历了delphi、C#、VB、java。这期间，编程行业的兴起可谓是日新月异，代码结构也产生了巨大的变化。
代码全在一个页面上的模式，到分工明确的三层设计，再到分布式架构设计。可谓进步不小，却也产生了很多问题。
为了分层而分层的三层设计模式，为了分布而分布的分布式，带来的危害却从没有人去思考。一个表建立一个添加一个项目号称自己多了一层；一个method创建一个WCF号称分布式广泛。仔细去想想，他们带来的混乱和最开始的所有代码都在一个页面上是一样的。这样的项目产生了巨大的难题，下面我来列举下：
第一、项目管理困难，三层项目过多，导致功能定位模糊，WCF项目数量过多，部署的项目也会很多。人员更替会造成模糊度进一步加剧，一旦积累到了一个爆发点，整个项目会宕机。
第二、可维护性和扩展性差。三层项目过多，WCF项目数量过多，改动数据库的时候会引起连锁反应，巨量的项目要改动，牵扯过多，导致项目进展缓慢。
第三、培训难度加大，上手难度太高。从没有一个公司没有人员流失，员工变动在所难免。三层项目过多，WCF项目数量过多时所产生的状况就是你的员工需要花费巨量的精力接收这部分的知识，甚至在你还没培训完别人就离职这种情况。
因此，我认为合理分层、分布式才是最好的。
注：作者的疯语，如果你不同意也勿喷
我一直认为在WCF做数据增删改的操作是不合理的，如果项目和WCF分属2个不同部门管理时，效率底下，而且产生BUG无法预知。
告：很多人一直认为代码的备注是没有用的，需求文档、设计文档、部署文档都是没有用的。我最近接手了个项目，以上一无所有，用的是数十个WCF操作数据库，我花了20天还是毫无头绪，心底产生了离职的念头。
标签：产生 扩展 c# 接收 创建 员工 离职 method 无法
原文地址：http://www.cnblogs.com/chonga/p/7605994.html
