一星期8天

好文章！虽然到后面有些现在不能完全理解，但是希望努力看懂!感谢楼主

当我们选择投票决定的时候，有些人总习惯性的选择弃权。。。

一直关注你的blog,怎么这么久不见更新了啊？有新的地址么？发给我看看好么？ 你写这篇文章的时候是06年，今天来看看，那个business流程就是DDD中的Service阿，Business对象就是Entity。 拜大牛

很好，我终于有点体会

以前用不少的代理、事件，今天看到楼主的博文有了新的理解；

没有体现工厂模式？

怎么没有Interface 啊？

学习了

这个是一本书上

@Kim Jueng Suk 的确很经常出现这类事情，开发人员做了一个东西出来，拿给客户看的时候，客户却说“为什么要这样做的？我想要的不是这样的”。我想这不仅仅是再与客户沟通方面的问题，也与开发人员的自作主张有很大的关系。

用户需要系统的原因是需要系统来帮助他们完成一些事情。 用户不知道什么是需求，只知道他的工作，工作是从其他人那接到工作，把工作完成后交给其他人，这是一个人的工作流程。工作流程中包含了商业流程。做需求不能为了工作流程而工作流程，要从中找出商业需求。

这些代码不应该是具体的程序代码，而是那些决定程序框架的代码，项目经理应该亲自弄清一个项目中的所有技术问题，确定排除一切实现上的风险。 你这个是典型的中国式项目经理，这个是架构师完成的工作 算了，我们这里也是这样的，在中国很少能跳出这个圈子的

我是一坨菜，看不懂 支持下吧

关键还要看值不值得积极

真诚的希望能早点看到“.NET初学者架构设计指南”的新篇章。我从中受益匪浅。

看完了楼主的4篇连载，谢谢博主的无私分享。好文！

励志 永远是主流

虽然不是很懂，但是还是要谢谢你的分享。

如果后来用户变更了需求：“当设备的电压连续一定时间大于额定电压的50%的时候，才将电源切断，否则不切电源，并且在切断电源2秒后，要重新尝试连接电源，发现电压仍然超过，就断开不再连接。”这样的需求变更就应该在“设备”这个抽象层次上进行。如果没有这个抽象层次，这个变更就比较麻烦了。


想问一下,这个"设备"上的抽象是指什么的抽象,是各种不同设备还是别的?

很牛!

呵呵 没必要讨论吧 存储过程的优点太明显了
我做的一个移动项目100以上的存储过程，不过基本都是我写的
哪些是通用的存储过程 哪些是数据接口的存储过程 哪些是WEB项目的
存储过程 只要事先分好类就行 命名并不麻烦
项目也因为移动扩容升级过几次 如果旧的存储过程无法满足要求
就换个新的 命名的时候统一加一个日期表示这一批的就行了 也没觉得维护麻烦：）
毕竟MSSQL没有ORACLE这样对命名还有长度限制！！！！

自己的优点就是自己的缺点 烦

很喜欢楼主用实例讲解的风格，这对于我这样的缺乏经验的开发人员来说相当有帮助

中学上计算机课老师就交了wps和打字

呵呵，这篇文章的结果是引起强烈的怀旧情绪……

现在看看这段话,真的是深有体会啊
态度在工作中很关键

LZ说的很有道理，现在我们的需求分析人员为什么做出来的需求，老变来变去，不够稳定，我想他们都是盯着业务流程绕来绕去，并没有抓住“商业需求”，这个根本。确实，用户想要的是实现自己最大商业价值的软件，而业务流程肯定要因此能适应这个变化。所以，一味要求客户不改变业务流程，那简直是自己砸自己饭碗！做为一个好的需求分析师，如果，站在实现用户商业价值这个角度上去思考，去做需求，去做一些前瞻性的思考，分析用户的一些使用习惯，才能抓住需求的本质，从而让公司占住主动，不会被客户牵着鼻子走。按常理，用户的商业需求，应该说是比较稳定，不稳定的是流程，我们做软件的时候要把流程单独独立出来，不要分散处理，这样修改的时候就会方便很多。本人做个很多项目，但能做到既能让客户满意又能让程序员满意的不是很多。我想这与做需求分析师和架构师有很大关系。程序员抱怨老改来改去，不停的加班，而客户也没有好脸色---“你们做的系统怎么这么烂，改一个东西就这么难吗”？本人有很多这样的经历，也不停的再思考。今天看LZ的这篇文章是有感而发，也期望自己在不久的将来能承担起这个双种角色！让客户满意，也让我的兄弟满意。

挺有感触的

学习了...

to: 金色海洋；

不太同意你的观点，我想做为一个开发者，如果像你所说，认为了解了客户的业务流程，就可以按自己的想法和思路设计和开发软件，还要影响客户的需求，那么这个工程存在很大的风险，甚至有可能导致失败！也真的有某些开发者，在技术上一流，很自信，或者说自大，擅自改变功能，他觉得这样的功能更漂亮，简直就是完美极了，而沾沾自喜，呵呵。结果呢？在验收的时候，客户不需要！
不错，确实，在需求分析阶段，分析人员可以引导客户回忆和确定需求，但这不叫影响客户的需求。当然需求也和全部的利益相关者有关系，包括了客户，实际使用者和开发者等等，但开发者所关心和负责的技术需求、所实现的功能也都是为了能运行客户的实际业务，这终归也是为了客户的业务需求而服务。所以，软件要怎么做，不能以开发者实现功能为主，还是要以客户的需求为主。希望所有开发者不要犯这种错误！！

很好。转了，呵~ 我原来看的时候就是事件实现的。现在看到这个感觉这个才是最根本的！

博主写的非常好，长了见识，有没有qq群，msn 什么的向你学习一下

同感啦，身有体会！
前几天在网上看到SP的一下优点还觉得是那么回事，可今天看来，可真还有那么一点“汗”啦！
1、执行速度比普通的SQL语句快
2、便于集中控制
3、可以降低网络的通信量
4、保证数据库的安全性和完整性
5、灵活性

可能就是因为它有这些有点，而使它的缺点也跟着出现。
SP真的好难维护，特别是在客户数不断增加的情况下，机子都快爆了。
现在维护把一些权限什么地全部搞坏了，头都大了。好想想个办法代替SP。
说不定就是人家所说的，自己的优点就是自己的缺点。

“每次上课前一天，我们需要沐浴更衣，剪好指甲。”是不是太夸张啦？？？我记得小学那时候是20多台东海的电脑，上课也就穿个鞋套而已啊！

看明白,这最重要

请问楼主怎样调用发送事件呀，刚接触VBA
我写了，不知道在哪里设置发送就调用

看了，很有启发

楼主接触电脑好早，我直到大二，也就是两年前才知道编程为何物。
其实我认为完全的面向对象在一定程度上复杂化了业务逻辑，而让面向对象和面向过程相结合才能更好的发挥程序的威力！

谢谢提供！

越到后面，理解就越难了。
但还是学习了不少，感谢博主的好文。
希望自己以后做项目时能有明确的思路。

对设计模式还是一知半解，只能慢慢参悟了。

看完深有感触啊。。怎么才能一开始就设计出灵活的框架呢？

都是高手啊，我接触电脑也是在小学，只是那时候是学打字。连操作系统是什么都忘记了。貌似学校就让我们上了3次课。

不错！ 看的很明白

非常感谢，我现在和你当初的处境差不多，你的这遍文章让我意识到自已不足的地方了，再次感谢。呵呵

有纯文本的浏览器：lynx，有windows版本

上网也用命令行如何，cmdgo.com

存储过程可以重复利用，减少代码的编写量。另外，存储过程能够提高效率，但是可能会给服务器带来负担

@金色海洋（jyk）
--引用--------------------------------------------------
金色海洋（jyk）: 面向过程、面向对象，之后是什么呢？我的想法是，面向功能。

因为对象是无限，儿功能是有限的。简单的说就是添加、修改、删除等有限的几个。

这几个都解决的，一个项目的一半以上的就都解决掉了。
--------------------------------------------------------
但一个大的项目会涉及很多东西,架够好不好,可重用性强不强

小项目目当然是无所谓了

不错的文章,简单易懂