第一，一种技术是否值钱，首先取决与市场价值，当然对于C#或者Java这类应用领域非常一致的商用语言来说，其实越难学的也就是工资越高的。越难学的工资越高这句话绝对是话糙理不糙。难学说明了人力成本中的培训成本会比较高，所以这类技术人员的工资确实就要高一些。那么.NET的超级工具，让我们开发起来超级方便的超级工具：VS.NET其实就是制约我们工资提升的最大障碍，老板会理直气壮的告诉你，会用VS.NET拖拖拉拉就能开发的程序员量产起来快得很，就这点工资你不老实干就开掉你换一个，你后头还有好几个找不到工作的.NET程序员供我选呢。

其二，.NET提供给我们的发展空间太狭窄了（或许是我眼光太狭窄），罗列一下之前我提到过的：wpf，wcf，wwf，Linq，ASP.NET MVC，微软把什么都做了，留给我们的除了傻乎乎的拿起linq，wcf，wwf去吭叱吭叱的码格子堆代码，还剩下些什么呢？架构设计？那是少数人的事情毕竟也轮不到程序员。做业务分析？那也是少数派报告。不可能一个项目从头开始全部手写代码吧？这样是不是活回去了？java程序员从Struts到Spring到Hibernate可谓武装到了牙齿。整套下来还不要钱，觉得Hibernate不合适还可以换ibatis，apache下头一大队候补的佳丽，可谓是后宫佳丽3千，试问.NET又能够靠什么让六宫粉黛无颜色呢？前有JAVA的堵截，后头还有ROR，Python，PHP，一大群追兵，从标榜自己开发起来不是一般得快的ROR（不知道沉得是否也快），到标榜自己跑起来飞快的Python（豆瓣的神话造就了Python的急速传说），还有标榜自己光膀子不怕穿鞋，完全免费的PHP。再换句话说，我们就坚定不移的跟着微软走吧，那么除了拿着VS.NET做网站，我们还剩下了些什么事情做呢，那就怪不得人家招JAVA的人多了，用JAVA做工作流中间件的可以卖钱，你用.NET试试，人家直接跟你说我们用WWF了，还用花钱用你的？做个ORM，MVC框架能卖钱？到处都是免费的，微软自带的，绝对没有任何一个开发企业会为了ORM还是MVC什么的花一分钱，要用都用开源的，所谓微软这种大包大揽的行为极大的打击了开源团队的积极性，MonoRails还没说要收钱呢，微软就忙不迭的搞了个自己的MVC框架出来。看着Java下第三方厂商的中间件热火朝天的时候，还真不知道我们应该在.NET下做点什么能卖钱的。

其三是我个人多年来在使用.NET的时候的积怨，其实我到现在为止都挺厌恶微软给.NET设计的API，太恶心，尤其是Drawing下边的哪些API流露出浓重的MFC的味道。而且异常处理的机制也异常的混乱，既然有了异常处理的机制就用异常来解决问题嘛，结果有的通过返回bool来提示错误，有的通过错误标示的参数来返回错误，异常也没有声明的机制，结果很多时候在使用一些类的时候根本不知道有哪些异常需要处理，很多新手就很笼统的给个Exception了事，那么这个异常处理的机制还有什么用呢？习惯了JAVA的声明式异常之后会很迷惑于这种模糊的方式。

还有一个很搞笑的地方就是异常的抛出：throw ex,throw,throw new XXException("error",ex);一个会中断异常的堆栈，一个不会另一个也不会，这不是多此一举么，简直就是茴香豆的回有四种写法。直接让throw ex不会中断异常堆栈就行了何必还要多此一举呢？

-------------------------------------------------------原文------------------------------------------------------------------------------------

还有一个很搞笑的地方是，你在捕获到一个异常的时候还不能直接把它抛出去，还要new一个异常，把捕获到的异常作为InnerException包裹一次后才能抛出去，不然在调试的时候就跟踪不到真正出现错误的地方而是在直接抛出的那个地方中断了。

-----------------------------------------------------------------------------------------------------------------------------------------------

都到了3.5了都还没有提供对DynamicProxy的支持，结果现在.NET下的AOP看起来都还是那么怪异，实现起来也麻烦。

其实发了很多牢骚，说.NET Sucks也不过是气话，我们无法否认.NET是一个伟大的开发平台，无法否认微软是一个伟大的公司，不过.NEt再伟大，得到利益的始终是微软而不是广大的开发人员而已。

其一，实体类是什么？

这里我做出一个符合大多数系统的定义：实体类就是只有属性且属性与数据库表的列定义一一对应，用途为在各个层次间传递数据的载体。也即是DTO（Data transfor object，大致这么拼写的）数据传输对象，java里叫pojo。那么我认为这个类的定义就是一个数据结构。

那么我们回过头来说数据结构。程序就是 数据结构+算法，这句话算是经典了，那么面向对象的程序里，类就是数据结构+算法的一个集合体，唯一的不同是面向对象提成封装，数据结构为私有，这样子通过方法作为契约来降低类之间的耦合度。但是，这不能从根本上解决问题。程序的数据不是内部 凭空而来，无论是输入还是输出都需要和外部由一个接口，那么这个时候这个接口就是一个耦合点。之前谈耦合的时候估计金同学没认真看，在接口的契约中，应该考虑采用标记耦合

------------无耻的自我引用----------------

标记耦合 ：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。

------------------------------------------

其实实体类就是这个：某一数据结构的子结构。

我们可以认为，数据库的结构也是一种数据结构（从数据结构的广义定义来说，确实是数据结构，数据存储的结构），那么实体类作为数据库表结构在程序中的映射来说也就是一种数据结构了。那么

CreateUser(UserEntity user)

这样子的“接口定义”（注意引号，此接口非彼接口）就是所谓的标记耦合了。

再对比一下公共耦合的定义：

------------无耻的自我引用----------------

公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

------------------------------------------

数据库作为全局的数据结构，自然也够得上公共耦合了，如果要真这么定义那么也没办法解决，这是个无解的问题，要用数据库就比如和这个公共的数据结构耦合。

而且，必须注意的一点是，耦合是模块之间的消息传递、数据传递的途径，耦合是中性的，不可避免的

所以在这点上努力是纯粹的在做无用功。也即是即使不用实体类，那么数据库的结构变了，也即是数据结构变了，那么修改代码是必然的，不可改变的结构。正如同操作数组做冒泡排序的算法如果把数组换成了hashtable还能正常工作？

DataSet，不管强类型的还是弱类型的，DataReader都是要和数据库耦合的，所以这两个和实体类没什么区别。

难道我们什么都不做？  答案是否定的

就我现在的观点来说，解决之道就是动态。ORM用实体的定义作为契约，动态化了对数据的访问，所以如果数据库发生了变更我们只需要修改实体类和定义，这就大大的减小了对程序的修改。spring动态化了对业务模块的依赖，我们可以很容易的替换业务模块。那么如果数据库发生了变更，在修改实体类和定义的基础上我们只需要数据库修改的表所涉及的业务模块用新的替换掉就ok了。而界面上，动态的表单和数据控件也能够极大的减小修改的幅度。

这里有一点是需要对金同学说明的：你的控件就算是用事件把一部分业务逻辑的工作剥离出来，但是业务逻辑是和数据耦合的，那么你用什么来让业务逻辑知道你的数据结构？数组？DataReader？DataSet？

表单所以依赖的数据结构变化了，配置变不变？所谓配置也就是程序的一个延续，我认为配置其实就是一种外置的DSL（见 why xml sucks）

修改配置文件和修改程序，很多时候由一个误解认为修改xml文件比修改程序好，殊不知xml文件的修改没有经过编译时的检测，而程序是通过了编译时检测的，修改xml的出错几率比修改程序高100倍（这点我好像在 why xml sucks 里头漏掉了）。

说回来，数据表的结构变化了，其实还是会涉及到对界面的修改，只不过你的控件把这个修 改从页面文件剥离出来，改成了修改配置文件（或者配置数据）。如果没有工具来完成配置的工作，出错的几率比修改页面高得多，且debug也复杂得多。

还有一点要对回复金同学疑问的一些同学说的：好多同学对spring的理解委实有很大的偏差。spring是一个ioc容器+aop容器+抽象服务的集合体，当然我们用的最多的是前两者。很多同学吧ioc和aop弄混了。ioc是依赖注入的概念，其实也就是对虚拟工厂模式和代理模式的实现，而aop是方法切片，也就是在调用方法的前面和后面动态的植入另外的要执行的代码（其实也就是方法）。

就技术上来说，多点SSO存在一下几点难题：

1. 多个注册服务器间的用户认证标示防止重复
2. 用户注册地址的定位
3. 跨域的认证状态同步（所有SSO都要解决的问题）
4. 注销登录状态的问题

对于第一点，一般来说可以借鉴SIP协议的方式。我们将用户的ID分成两段，前一段是注册站点内的ID然后在@后是网站的域名，结构上和Email地址差不多譬如Alexander-lee@cnblogs.com，假设cnblogs.com就是我注册的站点，在注册的时候我只需要输入Alexander-lee，然后自动在尾巴上给我加上@cnblogs.com。这样子每个站点注册的时候限制就可以达到最小。

同时，这个方式还可以达到定位用户注册服务器地址的作用，我们可以使用后面的域名信息来定位用户的注册位置，还是Alexander-lee@cnblogs.com，识字的人看到都知道在cnblogs.com注册的。

然后是跨域认证状态同步的问题。这个在拙作http://www.cnblogs.com/Alexander-Lee/archive/2007/01/27/631962.html中已经描述的很清楚，也是大多数SSO所采用的做法（个人不建议使用跨域Cookie或者js注入等技术，都容易被严格点的浏览器挡获）。

最后是注销登录状态的问题，这个在我原来的Post里面没有提到，对于单点SSO来说还算是比较简单的。但是对于多点SSO来说确是比较烦琐的事情了，因为需要清除多个服务器上的Cookie，还不能借助JS等客户端技术来完成的。最简单的方式就是所有站点全部使用非持久的Cookie，关闭浏览器就全部都失效了。但是如果是持久Cookie的话，个人来说还没有很好的主意，有一个想法就是在协议里规定一个Cookie用来存储所有登录过的服务器，然后在注销的时候一次一次的转跳到注销的接口页面（笨办法，期待高人给出比较简单的解决方案）。

其实写这些东西是因为看了http://www.cnblogs.com/chinaxiaofei/archive/2007/09/28/909920.html 这位高手的Post，看后感觉有很多问题没有谈到，也不是很完善，所以发此贴期待共同讨论。

首先是图书馆的用例：

其实用例的情况大家都很清楚了，简而概之就是用户在图书馆的书架上找到自己想要的书，然后向管理员出示借书卡后借到想要的书。

用例图。

这是一个很简单的用例，我没有分析完所有的用例以及子用例，这里到此就可以打住了，我们可以在以后的迭代过程当中来继续完善

然后根据需求我们来建立业务规则表：

规则一：借书需要出示身份证明以及借书卡   （来源：图书馆馆规）

规则二：每个用户一张借书卡 （来源：图书馆规定）

规则三：每张借书卡可以借N本书 （来源：图书馆规定）

然后得到领域模型：

这个模型也是一个很粗略的模型，不过足够我们开始下面的分析了。这个模型是动态的，在我们分析的过程中还可能发生变化。我们不要害怕变化，优秀的开发过程和设计模型都是应对变化的丰富实践经验的结晶。我们可以通过这个领域模型清楚的看到概念类的属性以及概念类之间的关系。注意，概念类不是我们在编程的过程中所写的类，当然对于很多简单的模型来说，领域里的概念类可以直接变成程序里的类，但是并不表示其之间可以画上等号，我们还需要继续分析系统中对象的行为。我们可以通过时序图和通信图来表示这些行为的过程。

我们在之前所界定的系统边界之内分析系统的操作，然后定义系统操作的操作契约。最后我们综合用例分析，领域模型和操作契约的分析，最终得到了系统的设计。

这里我们没有看到任何的代码，也不涉及任何贫血充血的争论，我们先建立一个粗略的模型，然后在实现的过程中不断的迭代优化它，最终实现我们的软件，不会出现过度设计，也不会出现一上手就是代码的盲目。

由于时间关系，LP吹促觉觉，故下文明日再说。

耦合度是用来度量代码块之间联系的程度的标准
耦合度是从模块外部考察模块的独立性程度。它用来衡量多个模块间的相互联系。一般来说，耦合度应从以下三方面来考虑，即：
耦合内容的数量，即模块间发生联系的数据和代码的多少，同这些数据和代码发生联系的模块的多少，多的耦合强，少的耦合弱；
模块间的耦合类型。耦合类型有以下几种方式：
①独立耦合
②数据耦合
③控制耦合
④公共耦合
⑤内容耦合
下面重点对各种类型的耦合作进一步的说明。
（1）独立耦合
两个模块完全没联系
（2）数据耦合
指两个模块彼此交换数据。如一个模块的输出数据是另一个模块的输入数据，或一个模块带参数调用另一个模块，下层模块又返回参数。应该说，在一个软件系统中，此种耦合是不可避免的，且有其积极意义。因为任何功能的实现都离不开数据的产生、表示和传递。数据耦合的联系程度也较低。譬如调用方法
（3）控制耦合
若在调用过程中，两个模块间传递的不是数据参数而是控制参数，则模块间的关系即为控制耦合。控制耦合属于中等程度的耦合，较之数据耦合模块间的联系更为紧密。但控制耦合不是一种必须存在的耦合。当被调用模块接收到控制信息作为输入参数时，说明该模块内部存在多个并列的逻辑路径，即有多个功能。
举个例子
public void Action(bool param)
{
    if(param)
    {
        //do something
    }else
    {
        //do something
    }
}
这个方法就存在控制耦合。
控制变量用以从多个功能中选择所要执行的部分，因而控制耦合是完全可以避免的。排除控制耦合可按如下步骤进行：
①找出模块调用时所用的一个或多个控制变量；
②在被调模块中根据控制变量找出所有的流程；
③将每一个流程分解为一个独立的模块；
④将原被调模块中的流程选择部分移到上层模块，变为调用判断。
通过以上变换，可以将控制耦合变为数据耦合。由于控制耦合增加了设计和理解的复杂程度，因此在模块设计时要尽量避免使用。当然，如果模块内每一个控制流程规模相对较小，彼此共性较多，使用控制耦合还是合算的。
（4）公共耦合
公共耦合又称公共环境耦合或数据区耦合。若多个模块对同一个数据区进行存取操作，它们之间的关系称为公共耦合。公共数据区可以是全程变量、共享的数据区、内存的公共复盖区、外存上的文件、物理设备等。当两个模块共享的数据很多，通过参数传递可能不方便时，可以使用公共耦合。公共耦合共享数据区的模块越多，数据区的规模越大，则耦合程度越强。公共耦合最弱的一种形式是：两个模块共享一个数据变量，一个模块只向里写数据，另一个模块只从里读数据。
当公共耦合程度很强时，会造成关系错综复杂，难以控制，错误传递机会增加，系统可靠性降低，可理解、维护性差。
（5）内容耦合
内容耦合是耦合程序最高的一种形式。若一个模块直接访问另一模块的内部代码或数据，即出现内容耦合。内容耦合的存在严重破坏了模块的独立性和系统的结构化，代码互相纠缠，运行错综复杂，程序的静态结构和动态结构很不一致，其恶劣结果往往不可预测。
内容耦合往往表现为以下几种形式：
①一个模块访问另一模块的内部代码或数据；
②一个模块不通过正常入口而转到另一个模块的内部（如使用GOTO语句或JMP指令直接进入另一模块内部，C#和JAVA里基本上不会出现，C++情况不明，望C++达人提供有效情报）；
③两个模块有一部分代码重迭（可能出现在汇编程序中，在一些非结构化的高级语言，如COBOL中也可能出现）；
④一个模块有多个入口（这意味着一个模块有多种功能）。
这里除了2，3两种情况，1和4都可能在面向对象的语言的代码里出现。
第一种情况主要是本来该类内部行为共享的公共方法被错误的设置为public并且被外部的对象使用了。或者是直接将一个对象的属性读取出来，运算的结果又重新写回了对象的另一个属性。还可能有其它情况，不过限于个人能力，暂不知晓，有知道的请告知。
就我个人来说，假如A类的对象有个Count属性，那么在累加的时候使用a.Count++我觉得还OK啦，还没有洁癖到非要去弄一个Upgrade的方法上去，当然如果这个Upgrade的动作还涉及到其他的状态，那就还是多个方法出来好了。
一般讲，在模块划分时，应当尽量使用数据耦合。少用控制耦合（尽量转成数据耦合），限制公共耦合的范围，完全不用内容耦合。

所以说封装并不是表明就不耦合了，但是封装可以降低耦合度。对于耦合度来说我们是应该尽量降低的（在时间金钱允许的情况下），低耦合代表着在应对变化时我们能够更加从容应对。
 

所谓面向对象的编程、设计、思想。我们用大白话来说。

面向对象就是用 某物（对象），是什么（类），有什么（对象的状态），能干什么（方法）的方式来描述程序的方法。这就是面向对象。

面向对象的程序的特征，封装性：也就是某物状态的改变，必须是他自己的行为来改变。

打个比方，我（人类），有钱（有什么），你（人类），要找我借钱（能干什么）。于是

class Man()
{
    private int money;
    public int Money
    {
        get{return money}
        set{money=value}
    }
    public void Borrow(Man Target,int Howmuch)
    {
        money+=Howmuch;
        Target.Money-=Howmuch;
    }
}
就是这个样子。这样子的写法是不对的，这样破坏类的封装性，我们绕过了Man的对象，直接去操作了对象的状态。这完全是强盗逻辑，跟你直接到我钱包里掏钱一样不可饶恕。所以，借钱这个动作还需要我来参与，你找我借钱，而我，要借给你钱。我们修改一下类的代码。我们给Man类增加一个Lend的方法，以封装在借出钱的时候对自身状态的改变。然后借钱的行为也要更改了。
class Man()
{
    private int money;
    public int Money
    {
        get{return money}
        set{money=value}
    }
    public bool Lend(int Howmuch)
    {
        if(Howmuch<money)
        {
            money-=Howmuch;
            return true;
        }else
        {
            return false;
        }
    }
    public void Borrow(Man Target,int Howmuch)
    {
        money+=Howmuch;
        Target.Lend(Howmuch);
    }
}
这样子的代码就是满足了封装性的原则，注意，封装既是特征，也是必须满足的条件，如果破坏了封装性原则那就是破坏了OO的原则。

这里回到了一个很实际的问题，失血模型为什么不OO。
我们定义了Book类，封装了Book的状态（属性）。如果我们用一个BookManager类去Save这本书（典型的失学模式的做法）。那么，我们在BookManager中如何保存？很多人在BookManager.Save里读取Book的属性，生成SQL，写数据库，返回执行结果。这样子OO么？不OO，因为这种做法完全破坏了封装性的原则。就跟之前借钱的例子一样。所以我们要在Book类增加一个Save方法，这个方法是用来维护Book类本身的状态的。而很多的ORM也能够给我们的类注入这类方法，使我们的的类具备持久化的能力。这样Book的属性，如何在数据库里存储，如何读取，如何删除都是Book自身来负责，因为在数据库里关于Book 的记录都是属于Book的状态，所以都需要Book自身来封装，使其透明化。

很多人在之前我写的Book.Save是否OO的话题里面说，觉得Book.Save方法仅仅是换了个位置。但是哪里知道，这个小小的改变却是一个原则性的问题。而至于双鱼座觉得在Save里加入上下文的参数更加符合实际情况，我个人觉的加和不加对Book类是否符合OO的原则没有太大的影响。
但是有和没有确是天壤之别了。

封装是保证系统的高内聚低耦合的很重要的设计原则。
还是用Book作为例子，如果你的Book需要添加一个属性来表示新的状态（换句俗话就是你在数据库里加列了，数据库变化了）。如果你的Book类自己维护了自己的持久化状态，那么你就只需要修改Book类的持久化状态的方法。如果你使用的VS2005的话，使用重构功能一次性就能把所影响到的地方全部修改（java的用Eclipse也有同样的功能）。而如果没有封装的话。那么你可能需要改的还有BookManager，如果在其他地方还用到了Book，可能还有数不清的代码在等着你改。为什么会麻烦，因为没有了封装，类和类之间产生了耦合。

下一章我们会接下来谈继承（也包括接口的Implement）