再问：项目的前期设计、架构与后期维护（如何应对变化）
自我说明一下，本人经验不多，基本上算个新人吧 呵呵 各位别见怪了，并且很不幸，没有进过IBM，Microsoft这类的顶尖IT公司， 最多也是游走在中小型公司，目前为止都还没有碰到一个心怡的team 所以对于项目的架构这块心里一直有几个疑问：

1：最开始的时候我接触了 “三层” 感觉它在一定程度上可以对项目解偶。 于是我逐渐把项目都转移成了三层。 实体类映射数据库的表，DAL集中处理底层的SQL数据问题， BLL处理业务逻辑，UI....  
  但慢慢的我发现这样并没有达到我想要的目的。 由于实体类与数据库是一一对应的，并且由于UI DAL BLL 之间的过度依赖导致数据库一旦有变动哪怕是字段的顺序发生变化也会引起DAL BLL UI的连带性改动，大家知道，这种改动是非常致命的。（举个例子：DAL取了一张表的数据后交由BLL处理，BLL把处理的结果给UI呈现出来，但这么做的的后果是带来了严重的偶合性，比如我在表里面增加了一个字段，那么很好，首先实体类要改，DAL的SQL语句要改，BLL要改，UI也要开刀。。。） 后来我知道这种三层是低级的， 其原因是DAL和数据库的字段之间的硬编码造成的。这种三层会附带有很高的偶合性。 不过话说回来 问题真出在这里吗？我自己也摸不透。


2：后来我又接触了ORM，几经转折，我又用上了NHibernate，这个确实要比之前的“硬编码”要好的多，也在一定程度上做到了“解偶”，但似乎还是不完美。如果有较大的改动时 修改DAL的工作远比上面那种的工作量要大，实体类要改，映射文件要改，与之有关联关系的表也要改。oh god。 很让人头疼的。我始终琢磨不透我到底是哪错了，前期设计不够？还是我对nhibernate不是很了解？ 希望大家点拨我一下。

3：终于来到了最终的、最源头的问题上面了：前期设计。 挺美好的一个词，但它的事却是大把大把的。每个人都说要把前期设计做好后面就会好很多了。说到这里我想提两个问题（1）前期设计你们每个人都能肯定做到最完美而把所有的东西都考虑进去吗？我想答案是否定的，(2)如果现在在你手上的是个私单或者是你个人想要做成去面试的项目的时候，当你一个人的时候你又能把前期的设计做到尽善尽美吗。我想答案更是否定的，那么你们又是怎么做的呢。 我真的很想听一下。


以上都是我在实际生活中遇到的一些个很实际的问题，没有很虚无的高谈阔论，仅仅是希望大家一起来交流一下，点拨一下“迷途”的我。

------解决方案--------------------
小菜来学习一下!
------解决方案--------------------
看看设计模式吧，网上很多，会让你明白的
1 面向接口编程
2 将变化的部分封装起来
3 优先使用组合，而不是继承
------解决方案--------------------
变化时难免的，准确的需求貌似在大型的软件项目中并不存在，所以希望有一个完整准确的需求规格说明是不现实的。

程序员要做的就是设计灵活的框架，可扩展性好，楼主描述的这些方法应用在合适的场景效果还是比较明显的，总之和模式一样，不要为了模式而模式，模式是一种经验的总结，模式不是万能的，它有自己的应用场景，这也就是为什么软件开发要比其他生产行业更困难。
------解决方案--------------------
设计模式
------解决方案--------------------
1 面向接口编程 
我的DAL（SQLDAL）是根据IDAL的接口来实现的 严格按照的“面向接口编程”。 在数据库的迁移上不存在问题。 主要是不能在业务的变化（需求的变化）上很好的做出应对。 

面向接口编程 也就是 面向抽象编程，你既然能够把数据库相关功能进行抽象，为何不对你的业务进行抽象呢？
------解决方案--------------------
1 面向接口编程 
我的DAL（SQLDAL）是根据IDAL的接口来实现的 严格按照的“面向接口编程”。 在数据库的迁移上不存在问题。 主要是不能在业务的变化（需求的变化）上很好的做出应对。 

需求的变化，只能是你能提前预料到，并将可能变化的部分抽象出来，封装，你预料不到的变化，那就没办法了，只能靠修改了，没有一个程序说能应付未来各种各样的需求变化而不改动的，能做到的只是尽量的改动最小

2 将变化的部分封装起来 
其实也就是给抽象化，只有抽象了，才能扩展，而且抽象也是为了解耦，才更有利于扩展，这个前提就是你应该提前考虑，那些可能扩展，并不是所有地方都封装

3 优先使用组合，而不是继承 
这话我不想回你了 设计模式我都快被下来了 代理 工厂 适配器 也是经常出现在我的项目里面。

既然你设计模式都懂这么多了，这些问题我觉得应该不是问题了
问题就在于，需求的变化，你只能尽可能的去预料，然后提前设计应对，尽量的少修改，想完全不去修改就能应付，是不可能的，除非每个地方都桥接，但是这太理想化了，你的想法可能也有点理想化了


------解决方案--------------------
数据库中table的schema是你这个应用程序中最基本的数据模型。其他一切business logic都是在这个基础上建立起来的。如果说你的数据库字段经常发生较大的变化，那么其他层次要相应的变化，这是无法避免的。但问题是，你为什么要较大的变字段？我觉得数据库中table结构的设计可能有些问题。

------解决方案--------------------
另外，如果一定要经常改表的结构的话，那么最好在你的程序里面，减少对table的依赖。比如一个service只维护某几个必要的table，其他的table不要触及（如果一定要知道某些table里的信息的话，通过service call来获得）。这样的话，一个table的schema的改变只能影响一小块程序。当然如果每个service对应的table都可以分开的话，一切都变得简单，这是最理想的情况。如果分不开，那么就把service分成一些组，每个组只维护某几个table。
我不知道你的应用程序是不是SOA，也不知道我说得是不是能解决你的问题，就权当参考吧。
------解决方案--------------------
不要推诿给前期设计...所有不在意料之中的变化都来源于与用户沟通的问题和需求分析的失败...

架构设计不是用来给决策失误和需求不明擦屁股的...
------解决方案--------------------
其实我到觉得更多的精力放在重构上比较好,前期设计只能是大概设计下整体结构，自己接单的话项目不会太大，重构应该比设计重要
------解决方案--------------------
xuexi xuexi xia
------解决方案--------------------
环境问题,很多事情只能云里雾里来,云里雾里去..