再问：项目的前期设计、架构与后期维护（如何应对变化）
自我说明一下，本人经验不多，基本上算个新人吧 呵呵 各位别见怪了，并且很不幸，没有进过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
[解决办法]
环境问题,很多事情只能云里雾里来,云里雾里去..
[解决办法]
一般分层就可以解决这些问题的80%。
[解决办法]
说到底还是哪一句..
都是灵感惹的祸...
[解决办法]
LZ真仍高人也
於LZ的疑，本人也是有切之痛。
需求都有可能，有些是通不足事先有想到
更有一些客今天想，可明天又有人跳出想那
在是疲於付。。。。
注此，看高人如何做到 抱化
[解决办法]
不，我倒是一法，以前做了一 代生成器，了只要重新生成就好了。
不在也不是什么好方法
好的方案是中得到字段，利用反射生成。
[解决办法]
好帖比顶
[解决办法]
呵呵。顶。任何的设计模式都是针对变化而做的封装。都有其适用的场合。
[解决办法]
设计的时候很多人一般都是凭感觉，而不是靠逻辑推论。如果有人在设计的时候，能够遵循一种严谨可靠的理论，那个人就是很牛了。
本人总结一下个人看法：
1，三层架构
三层架构的提出其作用：并不是修改的时候不改动代码。而是用来分出逻辑层面，利用修改代码。能够减少修改之后，出现未知BUG的产生。从而减少测试时间，便于维护，提高软件质量。并且业务逻辑层抽象出来，也有利于将来相同的业务逻辑的重用，或者作为服务发布。
2，ORM
关系论和对象论的桥梁。有的框架做得很简单，有的做得很复杂。看你自己怎么选择。你也可以自己去做一个框架。如果数据库变化很大时，修改ORM那些代码工作量是大，但是如果是存SQL，可能有时修改起来好像是快。但测试起来会很慢，未知BUG出现的机率大，软件质量得不到保障。
3，前期设计
好像方法有很多。不过本人只用一种，那就是迭代。前期快速做原型，捕获需求。需求搞定后再开始具体设计。如果能够快速的做出原型，那就要看本事了。因为做原型的时候，往往需要大刀阔斧的改动。
[解决办法]
如果你真的想知道答案，就请抛开那些ORM工具
从这里开始
1.原型框架设计
2.框架的渐进演变，进化，突变
3.变换视角去看待模型
实际上我认为 架构师在很多地方很像艺术设计者
比如珠宝首饰设计：一颗原钻，如何设计才能让他光彩夺目？实际上最初的设计可能仅仅是一个多棱柱
所以我们从来就不指望一次就定型，我们从来就是渐进演化。然后是变换视角，现在所谓的MVC实际就是控制论，和视角变换的产物（考虑一下那些做3d模型的，考虑一下3dmax的界面，灯光，效果，左视图，右视图----实际上你问这个问题本身就是因为你被数据晃花了眼，想象一下一颗切割好的钻石在不同角度的灯光和切面折射下的炫目光彩，实际钻石模型还是钻石模型，他没有变化，变化的只是你的视觉和灯光）
[解决办法]
变化是不可避免的，关键是怎样识别出变化的内容，并将其封装在可控的范围内
随需应变，知易行难
[解决办法]
再说说架构吧
我知道架构的后面肯定是模式一词， 听的多见的多用的多， 所以我也挺关心这个东西的。
有人说不要为了模式而模式， 我知道，当一个业务规则呈现出来的时候你完全可以用一个模式来隔离它所带来的变化。但如果出现一个它所隔离不了的呢? 哦 这个模式不合适 推翻了再换另一个吧。 我想说它带来的工作量也不小呀。
如果你一开始设计的模式，在需求的变化过程中，无法满足了，那就需要重构啊，架构，就是在一次次的重构中成熟，某个产品出来都是v1.0，v2.0，他们的版本升级，很多地方也是重构了，甚至有些地方重新做了，都有可能，也很常见
模式也是一劳永逸，设计模式中一句话这么说的，唯一不变的就是变化，我们要做的，就是尽量的将变化部分封装起来，但这不是程序设计的结果，而是过程
[解决办法]
感谢你的回答。 不是SOA。
我想根本问题应该是我的前期设计不够吧。
在公司的时候会有个team一起来做前期设计， 但是遇到私单的时候前期设计总是做的不够好，后期不是发现有遗漏就是需求有变化。 不知道是我的设计模式学的不够透彻还是经验不足，还是自己根本不是做架构的料。 你们觉得呢？
>> 变化是不可避免的， 我们不是 算命先生 也不是预言家。我们唯一能做的 是 变化的时候 我们尽可能快的响应变化。你既然 熟悉 模式 那 重构呢？ 为什么 不重构呢？ 为什么不为快速响应变化 而考虑一些问题呢？
既然变化不可避免 那么我们还是多考虑 如何快速响应变化吧！ 层模式 本来就存在 级联修改的问题 这 无法改变 。。。。
[解决办法]
在公司的时候会有个team一起来做前期设计， 但是遇到私单的时候前期设计总是做的不够好，后期不是发现有遗漏就是需求有变化
》》 你的意思是有个team一起来做前期设计 你们就能很好的适应变化？ 修改的地方很少？ 而你 自己接单时 就一切都乱了？ 如果真是那样 那需要考虑 人家为什么 可以 而 自己不可以 对了，难道不是因为 需求分析的问题 ？
[解决办法]
争论很尖锐，学习。。
[解决办法]
.
[解决办法]
呵呵，楼主不妨学习一下极限开发。
这种模式也许可以给你开解开解。
[解决办法]
Mark!
[解决办法]
请别拍我哦
系统功能的实现依赖于逻辑层处理，而逻辑层的处理又是建立在 识别的数据 的基础上的。
我觉得 识别数据 是解决问题的关键。 也就是说客户层向逻辑层提供 数据信息 ， 而逻辑层就
根据 数据的信息 来作出相应的逻辑操作。
数据信息：包括数据类型、用途、数据对应数据库的相关属性等。
举个列子：
客户层向逻辑层提供一个数据信息：
string str=“123，int，update，dbname,table_name，10101，price"
(将数据库dbname 中的表 table_name 中 id为 10101 的记录 的 price 字段值更新为 123（int型））
逻辑层接受到 str 后解析它，而后实现操作。
这么的话 要是应变能力是否能提高呢？
[解决办法]
[解决办法]
难道架构师不是从程序员发展而来的?
没具体开发过N个项目能当架构师?
[解决办法]
学习一下，先
[解决办法]
学习，谢谢经验分享！
[解决办法]
分层是条理化, 层与层之间的交互是关键.
楼主觉得"厌烦"的就是变化的, 简单来说"封装"之.
用户的这需求那需求的变动是不可避免的, 如果没有"变动",也就没有所谓的接口,封装等概念了.
另外也更说明了"需求分析"的重要性! 设计再好的东西,没有建立在正确的需求分析上,只能说是"垃圾".
"架构设计不是用来给决策失误和需求不明擦屁股的..." 再次引用一下. 呵.
[解决办法]
嘛
说到底我们也只能做到尽量接近需求，考虑变化
楼主说的那些点子，都是没有完美的解决之道的
也只能根据他们各自的思想，且不违反客户需求与时间需求，尽量做到
[解决办法]
这个问题困扰我很久了，学习，继续关注~
[解决办法]
加我QQ475452712大家共同探讨下
[解决办法]
我觉得最大的问题在于初期的需求...
时时刻刻和客户保持沟通，了解他们最贴切的需求是最重要的，沟通的越多，越有可能成功。
当然，设计的时候也要给可能的变化留有余地(这个很虚)..
[解决办法]
设计模式
[解决办法]
[解决办法]
学习
[解决办法]
来学习一下!
[解决办法]
不知道LZ会不会继续关注这个帖子啦。
事实上我的经验还没有LZ多，但是看到LZ的问题突然想起最近看到的一本书里有讲。
我建议LZ在需求分析阶段改进一下，如果你的项目不断的进行大的变动，肯定是需求设计阶段就有问题。
设计是从需求而来，建议LZ阅读《大象》，是一本写UML的书，里面写了很多如何对需求分析来设计，如何抽象，一个不好的抽象会导致后期很难修改。错误的抽象在设计阶段的最主要问题是在同一个设计视图中使用了不同粒度的用例，这样会导致后期需求变更时的问题。
我经验不多，可能所言都不准确，LZ参考下就好啦。
[解决办法]
学习了。
[解决办法]
up
------解决方案--------------------
好
[解决办法]
d
[解决办法]
1 楼主的问题提的很好，大家都是泛泛而谈，没有对楼主的问题有一个明确的解决方案，我认为实际问题的解决方案更能说明问题。
[解决办法]
不错。搬个板凳慢慢看。
[解决办法]
mark
[解决办法]
xuexi
[解决办法]
[解决办法]
对楼主的问题很有同感，也希望能同楼主多讨论这个话题
[解决办法]
..........................
[解决办法]
新人学习
[解决办法]
越简单越好。
没有统一的方法，只能是具体问题具体分析。
不过有些经验，可以谈一下的。
(1)需求要明确。[已经有的，将来可能要有的]
(2)计算机（程序员）不是万能的，需要让用户理解用计算机的方式来解决问题的方法。
(3)对于没有经验的用户，要改是必然的，不过怎么改法由你自己说了算。
[解决办法]
ＬＺ总是强调私单，也就是说只有你一个人做。ＬＺ的问题在于一个人想做完所有的事情，然后把这个私单的蛋糕独吞。事实上，一个人肯定是做不好这么多事情的，这也是为什么现在的软件都是大家一起合力完成的，个人英雄时代已经过去了。要想把一个软件做好，需要把蛋糕分给别人。
[解决办法]
观摩之
[解决办法]
打个标记，回头慢慢看各位大牛的心得
[解决办法]
对于你前两个问题，我想你是没有用到更有效的ORM工具而已。Hibernate在java中很流行的时候，我就觉得它很烂，很繁琐。
当你顶一个class，映射到关系数据库应该是1、2分钟之内的事，如果你觉得维护和调试那种映射很麻烦那么一定就是工具问题，NHibernate跟Hibernate一样麻烦。java中对RAD开发环境的能力远远比MS落后10年，所以追捧Hibernate的风气被一些迷信java的人带到.net来。
你为什么不使用各种远比维护NHibernate高效很多倍的方法和ORM呢？例如Linq to SQL就是一例。其实Linq to SQL也相当低效，你也可以自己写ORM，可以直接从class动态反射来产生策略。反射效率不是问题，因为反射仅需要进行一次就可以记录下来复用。
[解决办法]
关于3，其实前期设计很难做到具体。如果具体到编程，就已经到了可笑的地步了。但是那些不精通编程的老板喜欢这个，因为他更重视文档的作用，宁可多花6个月的时间让你搞详细文档也不希望在2个月动用3个人搞出一个程序。
我采用XP方法开发软件，对于2周内部完成的编程任务习惯上是很排斥的，并且要制定任务必先制定测试标准然后才动手。而所谓的“前期设计”其实就是制造垃圾，与XP相抵触。
只能勉强少制造垃圾而已。
[解决办法]
mark之
[解决办法]
对于2周内部完成的编程任务习惯上是很排斥的 --> 对于2周内不去完成的编程任务习惯上是很排斥的
编程提交的源代码也是一种副产品，真正有用的TDD源代码，但是如果公司不采用XP方法，我就不会提交体现核心思想的TDD源代码。
因此，我用一种实际可行的做法替代所谓的“前期设计”。但是除非给自己打工，否则未必总能用最好的做法。
[解决办法]
先接了分再回来看看
[解决办法]
。。。。。。
[解决办法]
不过要补充的是，再敏捷的开发，也不可能没有前期设计文档。只是形式不同而已。当你使用一种很好的方式保证开发不走弯路，那么你就可以几乎不写文档，但是你保证开发不走弯路的那个东西就应该是综合了创意和质量两个方面的、对业务逻辑考虑很全面的了。
所以并不是不应该写前期设计，而是跟工程方法有关。如果你开发时经常为了应付客户的心血来潮而破坏原来已经设计好的东西，那么你就需要先写好前期设计。问题你的工程方法就根本不能保证后期稳定和敏捷。
[解决办法]
回答的都很中肯
持续关注中。。。。。。
[解决办法]
又见sp1234。。。。。。。。
[解决办法]
感慨
[解决办法]
实际上我们并不是把矛头指向“前期设计”
我们是把矛头指向了“设计观念”，ORM和你的出现的问题，本质上是 基于集合论的关系数据库 和 基于进化论的面对对象观念的间 不适配 所造成的。
而要解决这种不适配，关键是观念上转变，就是即使是设计数据库也同样已对象的观念来设计，而非基于传统的数据库观念。实际上这点你可以在power designer这个工具上看的很明白，新版的PD，实际上完全可以当做一个OO设计的工具，而非传统的数据库设计工具
[解决办法]
JF,学习
[解决办法]
单个软件几十万的不知道算不算大项目。
我们主要是基于组件。把各种小东西封装。然后再用。
[解决办法]
顶这个
[解决办法]
适合才是重要的
[解决办法]
对于三层架构架个把字段引起级联修改这种小事不值一提.
因为这是纯体力活. 用不了多久.
软件工程就是要 先把脑力活=>体力活, 然后体力活=>交给机器自动完成.
[解决办法]
JF留名
[解决办法]
------解决方案--------------------
1 面向接口编程
2 将变化的部分封装起来
3 优先使用组合，而不是继承
同意。
[解决办法]
........
[解决办法]
适度设计+重构
小心过度设计
当然也得小心没有设计
说句那啥的话,唯有变化不变,
如果你有一个银弹系统,用之四海而皆准那这么多的软件公司还忙活个屁呢?
没有银弹
没有银弹
没有银弹
没有银弹
你这个问题我想没有什么合适的最终答案,只能有不太灵活的系统和比较灵活的系统,没有绝对灵活的系统
[解决办法]
多么有前途的帖子
顺便送上一句话，所谓精益的架构 不是说 有改动时，因为架构好了 就不需要改动代码
而是 尽可能少的改动代码，降低成本
不要指望 几乎不改代码
[解决办法]
mark
[解决办法]
留爪。。收藏再看。