13,190
社区成员
发帖
与我相关
我的任务
分享再问：项目的前期设计、架构与后期维护（如何应对变化）
自我说明一下，本人经验不多，基本上算个新人吧 呵呵 各位别见怪了，并且很不幸，没有进过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：最开始的时候我接触了 “三层” 感觉它在一定程度上可以对项目解偶。 于是我逐渐把项目都转移成了三层。 实体类映射数据库的表，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)如果现在在你手上的是个私单或者是你个人想要做成去面试的项目的时候，当你一个人的时候你又能把前期的设计做到尽善尽美吗。我想答案更是否定的，那么你们又是怎么做的呢。 我真的很想听一下。
以上都是我在实际生活中遇到的一些个很实际的问题，没有很虚无的高谈阔论，仅仅是希望大家一起来交流一下，点拨一下“迷途”的我。
...全文
请发表友善的回复…
发表回复
louti 2010-02-23
- 打赏
- 举报
回复内容太短了！围观一下。
qinqindodo 2010-02-21
- 打赏
- 举报
我觉得这个本身不是项目架构的问题。
多数是对项目的理解和控制能力的不足。
架构的目的，很大程度上是为了重构，保留可重用，稳定的部分。使整个系统保持在一个大体的开发思路下，便于后期的维护。同时，类似的结构也让一些代码生成工具提高了开发的效率。
而目前的构架，基本都是居于数据库之上的。
数据库的设计，很大程度上决定了业务逻辑可以变动的范围，更大的业务变更就需要改动库表。
这也是楼主的主要问题所在，业务的专业深入不够。经常被客户的要求左右。 作为私单或者小单，想来单子也不会太大，这样的反复也许还能在接受范围内，但是如果是公司的产品级的开发，业务的理解，是非常重要的一环。
作为工具和方式，只是各有千秋的实现手段，在mis级别，理解业务，完善数据库设计可能更为重要 .
^-^
多数是对项目的理解和控制能力的不足。
架构的目的，很大程度上是为了重构，保留可重用，稳定的部分。使整个系统保持在一个大体的开发思路下，便于后期的维护。同时，类似的结构也让一些代码生成工具提高了开发的效率。
而目前的构架，基本都是居于数据库之上的。
数据库的设计，很大程度上决定了业务逻辑可以变动的范围，更大的业务变更就需要改动库表。
这也是楼主的主要问题所在，业务的专业深入不够。经常被客户的要求左右。 作为私单或者小单，想来单子也不会太大，这样的反复也许还能在接受范围内，但是如果是公司的产品级的开发，业务的理解，是非常重要的一环。
作为工具和方式，只是各有千秋的实现手段，在mis级别，理解业务，完善数据库设计可能更为重要 .
^-^
ganzhongliang 2010-02-20
- 打赏
- 举报
我喜欢这个。。。
me_child 2010-01-20
- 打赏
- 举报
[Quote=引用 146 楼 hwonner 的回复:]
引用 145 楼 me_child 的回复:
连结帖了都不忘回复啊 不过没分了哦。
不要分,对你有用就好.
这个架构,也是我目前正在实用的, 不仅仅是理论.
[/Quote]
呵呵 3Q
引用 145 楼 me_child 的回复:
连结帖了都不忘回复啊 不过没分了哦。
不要分,对你有用就好.
这个架构,也是我目前正在实用的, 不仅仅是理论.
[/Quote]
呵呵 3Q
予沁安 2010-01-20
- 打赏
- 举报
[Quote=引用 145 楼 me_child 的回复:]
连结帖了都不忘回复啊 不过没分了哦。
[/Quote]
不要分,对你有用就好.
这个架构,也是我目前正在实用的, 不仅仅是理论.
连结帖了都不忘回复啊 不过没分了哦。
[/Quote]
不要分,对你有用就好.
这个架构,也是我目前正在实用的, 不仅仅是理论.
me_child 2010-01-18
- 打赏
- 举报
[Quote=引用 144 楼 hwonner 的回复:]
1. 三层结构,我把它看成动态结构(运行时), 因为三层的依赖关系是: UI--> 业务 --> 数据层
而从业务领域驱动的角度，它们的依赖关系为：UI --> 业务领域; 数据层 --> 业务领域. 这里，业务领域层，是核心， 而且与ＵＩ 和数据层（库）无关．
２．业务领域模型的设计(OO)与数据模型（ＥＲ）设计应该是相互独立的；然后之间的映射(Mapper)可用nHibernate
3. 如果把第二点考虑进来，以来关系应为：ORM --> 业务领域；数据层层 -->业务领域．
ＵＩ也可做类似的改进．
这样一来，三层都完全独立出来，互相不受影响，具体实现上要用到面向接口编程和依赖注入(IoC, Dependency inject) http://en.wikipedia.org/wiki/Dependency_injection
[/Quote]
连结帖了都不忘回复啊 不过没分了哦。
1. 三层结构,我把它看成动态结构(运行时), 因为三层的依赖关系是: UI--> 业务 --> 数据层
而从业务领域驱动的角度，它们的依赖关系为：UI --> 业务领域; 数据层 --> 业务领域. 这里，业务领域层，是核心， 而且与ＵＩ 和数据层（库）无关．
２．业务领域模型的设计(OO)与数据模型（ＥＲ）设计应该是相互独立的；然后之间的映射(Mapper)可用nHibernate
3. 如果把第二点考虑进来，以来关系应为：ORM --> 业务领域；数据层层 -->业务领域．
ＵＩ也可做类似的改进．
这样一来，三层都完全独立出来，互相不受影响，具体实现上要用到面向接口编程和依赖注入(IoC, Dependency inject) http://en.wikipedia.org/wiki/Dependency_injection
[/Quote]
连结帖了都不忘回复啊 不过没分了哦。
予沁安 2010-01-15
- 打赏
- 举报
1. 三层结构,我把它看成动态结构(运行时), 因为三层的依赖关系是: UI--> 业务 --> 数据层
而从业务领域驱动的角度，它们的依赖关系为：UI --> 业务领域; 数据层 --> 业务领域. 这里，业务领域层，是核心， 而且与ＵＩ 和数据层（库）无关．
２．业务领域模型的设计(OO)与数据模型（ＥＲ）设计应该是相互独立的；然后之间的映射(Mapper)可用nHibernate
3. 如果把第二点考虑进来，以来关系应为：ORM --> 业务领域；数据层层 -->业务领域．
ＵＩ也可做类似的改进．
这样一来，三层都完全独立出来，互相不受影响，具体实现上要用到面向接口编程和依赖注入(IoC, Dependency inject) http://en.wikipedia.org/wiki/Dependency_injection
而从业务领域驱动的角度，它们的依赖关系为：UI --> 业务领域; 数据层 --> 业务领域. 这里，业务领域层，是核心， 而且与ＵＩ 和数据层（库）无关．
２．业务领域模型的设计(OO)与数据模型（ＥＲ）设计应该是相互独立的；然后之间的映射(Mapper)可用nHibernate
3. 如果把第二点考虑进来，以来关系应为：ORM --> 业务领域；数据层层 -->业务领域．
ＵＩ也可做类似的改进．
这样一来，三层都完全独立出来，互相不受影响，具体实现上要用到面向接口编程和依赖注入(IoC, Dependency inject) http://en.wikipedia.org/wiki/Dependency_injection
WuBill 2010-01-12
- 打赏
- 举报
学习
yingyuebingya 2010-01-10
- 打赏
- 举报
[Quote=引用 35 楼 vrhero 的回复:]
引用 26 楼 me_child 的回复:
最难做设计的应属那些中小型项目。 这种项目的客户往往对技术不懂或者一知半解（这种最可怕），
这又是在推诿责任，呵呵...客户凭什么要对技术懂或者全知全解？他们都明白了还要我们干什么？
为什么会出现“中小型项目难做”？原因不外乎...
1.较小的公司舍不得花主力程序的薪水去请经验丰富的领域顾问，一般多是薪水还不如初级Coder的小年轻做需求，还有很多公司直接就是PM、程序甚至市场去做这种他们做不了的事...结果他们去是“听”需求而不是“分析”需求的...自然这种需求只是用户自己想的或道听途说的，你都知道他们不懂技术这些需求能准吗？用户不知道他真正想要的是什么是很正常的...所以才要沟通、分析，业内常说挖需求挖需求，一个“挖”字最好的阐述了需求分析的内容...
2.这样的公司通常也舍不得花大价钱请经验丰富的架构师，很多都是PM兼、需求分析师兼、甚至程序兼...且不说他们有没有能力做，他们站的立场就决定了会出问题...最可怕的就是程序兼，前面需求一塌糊涂，后面程序却严重理想化，自顾自关起门来“听”着需求分析“听来”的用户需求闭门造车...需求分析师兼也好不到哪里去，自己按自己听来的自顾自作，即代表用户又代表程序最后无所适从...PM兼也很糟糕，项目压力时时在头顶，能应付就应付能凑合就凑合，一锤子买卖顾不了将来...
3.最重要的是...这样的公司几乎都是完全不敢得罪用户的，用户说一就是一说二就是二，不合理不应该的都满口应承下来不管实现得了实现不了影响有多大...一说这个大家都一肚子苦水，小公司不容易啊...但是这不是问题的症结所在...还是因为前两点，你的需求分析师不专业，既没有挖掘到用户的深层需求也没有起到引导用户的作用...用户当然想啥说啥，他不懂啊，可你如果不能用让他(注意是让他不是让你)信服的理由驳倒他，他当然认为这个变化是应该的...最后这个变化压到设计头上，可你凭什么需要一个可应对未知变化的系统？架构设计凭什么不能说不？
所以归根结底是因为沟通...需求分析人员和用户沟通出问题，需求分析人员和架构或程序沟通出问题，PM和架构或程序沟通出问题，时不时老板或高层管理人员也要在需求上技术上横插一脚...能不变化吗？这些变化能在意料之中吗？这些变化能可控吗？
技术是用来解决已知问题的，不该承担太多责任...
[/Quote]
最近正受到这方面得困扰，多谢！
引用 26 楼 me_child 的回复:
最难做设计的应属那些中小型项目。 这种项目的客户往往对技术不懂或者一知半解（这种最可怕），
这又是在推诿责任，呵呵...客户凭什么要对技术懂或者全知全解？他们都明白了还要我们干什么？
为什么会出现“中小型项目难做”？原因不外乎...
1.较小的公司舍不得花主力程序的薪水去请经验丰富的领域顾问，一般多是薪水还不如初级Coder的小年轻做需求，还有很多公司直接就是PM、程序甚至市场去做这种他们做不了的事...结果他们去是“听”需求而不是“分析”需求的...自然这种需求只是用户自己想的或道听途说的，你都知道他们不懂技术这些需求能准吗？用户不知道他真正想要的是什么是很正常的...所以才要沟通、分析，业内常说挖需求挖需求，一个“挖”字最好的阐述了需求分析的内容...
2.这样的公司通常也舍不得花大价钱请经验丰富的架构师，很多都是PM兼、需求分析师兼、甚至程序兼...且不说他们有没有能力做，他们站的立场就决定了会出问题...最可怕的就是程序兼，前面需求一塌糊涂，后面程序却严重理想化，自顾自关起门来“听”着需求分析“听来”的用户需求闭门造车...需求分析师兼也好不到哪里去，自己按自己听来的自顾自作，即代表用户又代表程序最后无所适从...PM兼也很糟糕，项目压力时时在头顶，能应付就应付能凑合就凑合，一锤子买卖顾不了将来...
3.最重要的是...这样的公司几乎都是完全不敢得罪用户的，用户说一就是一说二就是二，不合理不应该的都满口应承下来不管实现得了实现不了影响有多大...一说这个大家都一肚子苦水，小公司不容易啊...但是这不是问题的症结所在...还是因为前两点，你的需求分析师不专业，既没有挖掘到用户的深层需求也没有起到引导用户的作用...用户当然想啥说啥，他不懂啊，可你如果不能用让他(注意是让他不是让你)信服的理由驳倒他，他当然认为这个变化是应该的...最后这个变化压到设计头上，可你凭什么需要一个可应对未知变化的系统？架构设计凭什么不能说不？
所以归根结底是因为沟通...需求分析人员和用户沟通出问题，需求分析人员和架构或程序沟通出问题，PM和架构或程序沟通出问题，时不时老板或高层管理人员也要在需求上技术上横插一脚...能不变化吗？这些变化能在意料之中吗？这些变化能可控吗？
技术是用来解决已知问题的，不该承担太多责任...
[/Quote]
最近正受到这方面得困扰，多谢！
比墨 2010-01-10
- 打赏
- 举报
学习了，设计很重要，分析更要求要到位。。。
alex12qwer 2010-01-09
- 打赏
- 举报
学习
ivfangwang_long 2010-01-09
- 打赏
- 举报
顶了~~~~~~~~~~~~~~~~~~~~~~
cs207 2010-01-09
- 打赏
- 举报
终于来到了最终的、最源头的问题上面了：前期设计。 挺美好的一个词，但它的事却是大把大把的。每个人都说要把前期设计做好后面就会好很多了。说到这里我想提两个问题（1）前期设计你们每个人都能肯定做到最完美而把所有的东西都考虑进去吗？我想答案是否定的，(2)如果现在在你手上的是个私单或者是你个人想要做成去面试的项目的时候，当你一个人的时候你又能把前期的设计做到尽善尽美吗。我想答案更是否定的，那么你们又是怎么做的呢。 我真的很想听一下。 --------------------------
这种瀑布式开发已经落伍了。
我觉得你的问题不在于“如何通过设计3层结构以达到低耦合”，
建议楼主看看软件工程的知识。
这种瀑布式开发已经落伍了。
我觉得你的问题不在于“如何通过设计3层结构以达到低耦合”，
建议楼主看看软件工程的知识。
sjjf 2010-01-09
- 打赏
- 举报
mark
zj_action 2010-01-09
- 打赏
- 举报
顶。。。
江南孤鹜 2010-01-09
- 打赏
- 举报
看了各位高手的激烈讨论。收获颇丰啊。。。。。看来需求分析是软件开发中最重要的一个阶段，它自始至终地贯穿于整个项目开发过程。设计模式也挺重要的，以后要重点学习啦。
飞天赤狐 2010-01-08
- 打赏
- 举报
迷茫中，
raylarer 2010-01-08
- 打赏
- 举报
受益匪浅！！3ks
人到中年琐事多 2010-01-08
- 打赏
- 举报
看看一位架构师写的书(设计模式--C#工程化实现及扩展,王翔),他提到,所有对象都是IObjectBuilder生产出来的
而所有的对象定义都写在配置文件里,如果能象他那样实现,所有的变化都不用重新改代码,重新编译了,直接改配置文件,或者增加一些Dll程序集.多爽啊,实际上代码里只是一些接口啊,抽象类啊等虚的东西.
但是真这样就好了吗? 这样就真好了吗?
而所有的对象定义都写在配置文件里,如果能象他那样实现,所有的变化都不用重新改代码,重新编译了,直接改配置文件,或者增加一些Dll程序集.多爽啊,实际上代码里只是一些接口啊,抽象类啊等虚的东西.
但是真这样就好了吗? 这样就真好了吗?
wgp198313 2010-01-08
- 打赏
- 举报
学习了.
加载更多回复（127）
