提到代理，就是客户端与服务器通信的桥梁，模拟服务提供的功能，关键一点就是接口和数据。
框架的代理，刚开始我是参照微软的WS的用法，是采用调用的方式，后来看到.Net3.0的调用方法，眼睛一亮，决定采用，想了好几天，才想起来应该是通过透明代理实现的。由于在服务加载的时候，也是用透明代理进行对调用的拦截的，这里的实现思路是一致的。
    

public interface CityServiceSO
    {
        /**//// <summary>
        /// 查找所有数据
        /// </summary>
        DataCollection<CitySDO> FindAll();
    }
    
    public class CityServiceSOI : ExecuteProxy<CityServiceSO>, CityServiceSO
    {
        /**//// <summary>
        /// 查找所有数据
        /// </summary>
        public DataCollection<CitySDO> FindAll()
        {
            return Proxy.FindAll();
        }
    }

      从上面的调用可以看的出，在基类里提供了一个Proxy的泛形属性，并实现其接口，在调用的时候，实现切入点，在调用点转入后台调用。与实现原来实现的调用一样，只是表现形式上有所差异，代码更简洁。
核心也就是重写：public override IMessage Invoke(IMessage message)这个函数。可以在此对调用进行更多的控制。
此处主要提供了两个调用，一个是Local一个是Remoting，主要是针对是服务调用还是本地调用，从而实现根据配置文件不同而实现本地激活和远程服务器激活，具体使用的信道由配置文件决定，默认走的是Http信道。
      

public override IMessage Invoke(IMessage message)
        {
            IMessage rltMessage;
            try
            {
                IMethodCallMessage methodCall = message as IMethodCallMessage;
                if (methodCall == null)
                {
                    throw new E2EException("调用参数不能为空");
                }
                MethodData methodData = this.GetMethodData(methodCall);
                switch (methodData.MethodType)
                {
                    case MethodType.Remoting:
                        return this.InvokeRemoting(methodCall, methodData);

                    case MethodType.Local:
                        return this.InvokeLocal(methodCall);

                    case MethodType.Object:
                        return this.InvokeObject(methodCall);

                    case MethodType.GetType:
                        return this.InvokeGetType(methodCall);
                }

                throw new E2EException("错误的代理类型");
            }
            catch (Exception exception)
            {
                
                rltMessage = this.CreateReturnMessage(exception, message as IMethodCallMessage);
            }
            return rltMessage;
        }

  
      调用的切入实现了，下面就要实现远程调用了。远程调用，主要是为了实现服务器端激活，由于服务加载层的存在，由远程调用只需要把使用的类的全名、调用的函数和参数传递过来就可实现远程调用。
这一块在这里不进行过多的叙述了。

关于WebForm和MVC我感觉应该不是一个概念上的东西，没有比较的地方。一个是设计模式，一个网页，怎么能够合在一起比较呢？企业级应用与WebForm与MVC也不是一个概念上的东西，也没有比较必要。就如ocean所说，里面有很多地方是在偷换概念。

MVC只是设计模式，你是WebForm展现，还是用WinForm展现，好像都没有关系，再跟企业级的开发牵扯到一起，好像是更乱了。

对于设计模式，我感觉关键是你的OO基本功如何，完全没有必要为了使用某种设计模式而用那种设计模式。举个例子吧，IUser oIUser = (IUser) ServiceLocator. getService ("UserInfor")，这种用法可以已经深入了一些朋友的心底了，当然好处多多。只是我再多问一句，为什么一定要这样使用？IUser　oIUser= ServiceLocator< IUser>. getService()，或IUser　oIUser= ServiceLocator< IUser>. getService(“UserInfor”)这样的写法呢？应该是可以达到一样的功能。当然，思想还是一样的思想，便是达到的效果却是不一样了。因为一个需要强制转换，一个不需要强制转换。一种在编译的时候就能够找出这些存在的Bug，一种是要在运行的时候才能够出现存在的Bug，虽然只是一点点的改变，对软件的影响应该是比较大的。再深入的问一下，为什么一定要用接口呢？又一大堆用接口的理由。对于一些场合是必须要用接口的，但是还有很多地方，是可以不用接口的，特别是在我们一般的应用软件开发过程里，维护一个文件应该比维护两个文件要轻松一些。当然，用这种方法比较容易实现切入点，如果是从这点方面去考虑，那是要用的，毕竟有那么成熟的框架支持，如果仅仅是为了用这种方式而用这种方式，就要考虑考虑了。但是上面所提到的那两种调用方式，应该可以取代提到的那种方式。当然，实现切入的话，也有其他的方式，我们可以考虑考虑，比较一下。说了这么多，我不是在比较哪种好，哪种不好，只是要提醒不要人云亦云，要有自己的想法，不要为了某种设计模式而去用这种设计模式。只所以接到这个接口，也是在一个博友的Blog里看到这句话，才提上来的。

对于设计方面，按照企业应用架构模式上的说法，领域模型、表入口模型、脚本模型，如果你是按照领域模型组织的，那么那些设计模式你会自然而然的用上去的，可能你还不知道这个模式叫什么名字，核心还是你的OO的基础。如果你是用脚本模型，还要硬套完整的设计模式，我感觉就完全没有这个必要。如果不是搞分布式程序的，没有独立的应用服务器，那么，远程激活、服务定位，好像都是多余的考虑。

WebForm，就是BS客户端。在我的观念中，客户端通常分为两种，胖客户端与瘦客户端，现在的什么富客户端，也是属于瘦客户端。反正在我的软件中，以BS＋CS结合比较多，所以呢，我通常不会去考虑要采用BS还是CS的，因为我两种客户端都要提供的，呵呵。

说到企业级应用，要说的，可就是太多了，真是剪不断理还乱的感觉，我感觉应该是应用软件领域里面，最复杂的一块。设计一个框架就是在玩平衡木，玩艺术，没有最好的只有更适合的。单机性能最优，不能代表多机性能最优。是资金、技术、周期、性能、伸缩、安全、扩展、集成等等诸方面的综合。仅仅从WebForm、MVC方面就说什么企业级的应用，应该是远远远远不够的，不要被这本书上那本书，动不动就是企业级应用搞晕了头脑。

到这里也不知道说了些什么，也有些文不对题，只是把自己的想法写下来，跟朋友们交流一下，只是个人观点，朋友们别扔西红柿呀
　　　
　　 那个Linq　To Sql与我的ORM的性能测试还没有做，不说了。应该做测试了…

对于服务层、DTO/SDO层、数据交换层，我个人感觉难度要比ORM那块要一些，可能大家通常对于ORM那一块的关注比较多一点，这一块关注的人估计要相对少一点。希望大家能够给我多提些批评建议…

可能有的朋友会说，这又是重新发明轮子，又是一个时间先后的问题，3.0出来之后，我也曾考虑把这一块换WCF，但是用起来，发现WCF用起来不是很方便，特别是在服务加载那一块，很麻烦的，对于通常的项目来说，真的没有必要。

还是快点把这个理一下吧。名词我不知道应该如何准确的定义，朋友们给个建议。

一、逻辑代码服务层：

主要是实现把BO的逻辑转换成更粗粒度的服务，实现服务的集成。另外，通常一个Data可以对应多个DTO/SDO，那么，要业务逻辑层不变的情况不，就可以改变对客户端的数据输出，此时，只要改变一下DTO/SDO和再添加一个方法就可以了，业务逻辑层代码不用作任何改变。此处要注意的就是对于事务的处理了，如何集成数据来自于其他的系统，特别是跨Internet的事务，这个就非常讨厌了，我现在还没有能力解决，对于局域网的事务要好一些，用TIP可以方便的加入到事务中。

这里还要考虑的是对于BS和CS的应用，CS应用通常是通过代理接入服务层的，BS应用可能通过代理，也可能不通过代理接入服务层。那么，对于采用声明事务，要对通过代理和不通过代理提供完全一样功能。这样提出了这样一个要求，对于函数的调用，必须要提供拦截的功能，通常的做法是用透明代理。我现在这里用的是ContextBoundObject这个基类，虽然可以使用，感觉不是很理想，不支持泛形。在函数调用new ()的时候，由IContextAttribute切换到代理。RealProxy在服务层里面用的是很多的，也是个关键。还有什么实现DynamicProxy等等，处理思想都是相似的，实现方式有所差异。

二、服务加载层

服务加载层，就是根据配置文件，把服务加载到内存里，实现服务器端激活。当第一次调用的时候，根据配置文件，把服务加载到内存里，当实例化的时候切入对于自定义属性的访问。当调用一个函数的时候，根据传入的服务类的类名、函数名，从缓存里查到这个实例的函数，再通过反射调用这个函数。主要的就是在配置文件加载上面了。

三、服务信道层

从上面的思想，应该可以看的出来，信道只是提供一个数据传输的通道罢了，通过Http/TCPIP/MQ/SMTP等等，都一样，要做的就是按照一定的格式，把数据从客户端传到服务器端，再把调用返回的数据写入信道，这就是信道要做的。具体的调用由服务加载层做。只要完成了一个，其他的几种都是相类似的，只是提供的协议不同罢了。

再深入的介绍可能要花很多的篇幅，如果大家感兴趣的话，可以深入的讨论讨论。

跟WCF的区别是，服务层依赖于配置文件，只有一个入口文件，如果用WCF，要么是.asmx要么是.srv，每一个服务对应着一个文件，只要业务代码写好了。就可以非常方便的加入到服务里面去，服务的变更非常方便，走Http/TCPIP都可以，切换也非常方便,不用更改任何代码，不用在服务上面多花精力。刚开始也是采用面向接口的方式，改进之后，去掉了，太麻烦，因为很多东西代码工具生成的，有时候需要手工调整，要同时维护着两个文件，加大了工作量。

算了，不说了，有点累了…

上面粗粗的介绍了ORM层、业务层。ORM主要是在数据访问，把程序从千篇一率的存储过程调用，从容易出错的Sql语句中解脱出来；业务层主要是规范业务逻辑的组织，简化事务处理，把精力用到处理业务逻辑的刀刃上。对于很小的BS软件，有这两层已经算是可以用了，但如果要考虑到集成、客户端，就会感觉只有这些还是远远不够的，数据处理的灵活性还不够，客户端界面的展示与业务逻辑层耦合的太紧密。

下面就要介绍到数据交换层、服务层、DTO层。我先从DTO层介绍吧，对于DTO层，有的朋友可能会感觉没有存在的必要，多了一层，也或许是这样。复杂度，工作量，对人的要求也高了，成本也高了，等等，都是要考虑的方面。

DTO层，也就是在服务器端和客户端进行沟通的，把业务逻辑层的数据传输到客户端，再把客户端的数据传输到服务器端，既然这样，那么在DTO与逻辑层数据Data之间就存在一个数据交换，数据交换在后面再介绍。DTO的数据要能够支持客户端的数据绑定，可能有的朋友会问，用业务层的数据不可以吗？答案是：如果是在局域网内可以，在广域网上不可以。业务层的数据存在很多数据是延迟加载过来的，在网络上传输数据通常是要求一次把比较多的数据传输过去，也就是通常的粗粒度设计，建立连接等开销太大、时延太大了。另外，客户端需要哪些数据，需要传输哪些数据，业务逻辑层不清楚，业务层只知道我能够提供哪些数据，DTO是知道我需要哪数据，两者所站的角度不同。业务逻辑层的数据相当于数据的提供者，DTO是数据的消费者。朋友们，再发挥一下想像，是不是可以这么理解，因为这个的存在，业务逻辑层设计的时候，可以不考虑界面是如何显示的，只要关心我的业务逻辑就可以，只要我能够提供这些数据就可以了，你是从一个对象里面得到的，还是从几个关联对象里面找到的，还是从别的系统里通过WebService得到的，业务逻辑层不关心，关心的是业务逻辑层可以提供这么多数据就够了，对于客户端，只关心有这么数据我可以处理，你是从哪里得到，客户端不关心，只关心我有这么多的数据可以处理。这样，就可以实现客户端与服务器端分离开发，设计的时候更重要的是针对中间的服务和要处理的数据设计，或许就是面向契约和服务设计吧。

借用SDO的一张图。

看了这张图，我估计很多人是非常熟悉的，如果从上面的观点和角度去考虑DTO的问题，那么这张图是自然而然的事情了，或许也是框架升级的一个必然趋势吧。这张图我是在2007年的9月份才看到的，但是时候完整的框架已经开始使用了，思想应该是相似的。

不过，这个DTO/SDO当时真的害的我很辛苦。

DTO要能够支持：数据绑定、历史记录、级联触发、合并集合、序列化与反序列化，要实现一个大的递归，从其中的任何一个对象开始，能够找出整个传递的所有数据。

1、                    数据的绑定支持。要实现IEditableObject接口，对于状态的变化要实现INotifyPropertyChanged接口，INotifyPropertyChanged接口也是微软在2.0里面新添加的，估计也是为了实现数据的双向绑定而专门添加的。实现了这两个接口，微软会自动调用的。对于容纳这些数据的集合也要支持绑定处理，则要IBindingList实现接口，这样才能够实现数据的触发，这样就要实现一个对象能够找到其所有的集合，一个集合要能够其所有的对象，这样一样，就必须实现从对象、集合、对象的递归，再深入一点，就实现了数据的级联触发，实现了双向数据触发、绑定。数据源的每个属性变更，要能够在界面上反映出来，绑定界面的改变，能够记录到后台的数据源，并且要能够支持回滚。

2、                    对于历史记录。当实现IEditableObject这个接口，则必然实现了历史记录，对于SDO来说，就是ChangeSummary。能够找到集合的所有更改的记录，包括删除的记录。对于单个对象而言是能够得到历史记录和当前数据，对于集合而言，则能够找出差异集，同时，集合也要具备集合回滚的功能。

3、                    级联触发，则是在实现数据绑定的基础上的，对于常见的主从结构，当从对象的一个属性改变了，要能够自动通知其所在的集合、集合再通知所在的对象数据改变了，如果是多层结构，则能够自动的从最底层开始一路通知到顶层。

4、                    合并集合、集合的处理。集合的处理与数据绑定是直接相当的。数据源找出差异集之后，要对差异集进行处理，处理完之后，要对原始集合进行更进一步的处理，要把两个集合进行合并处理，主要是为了同步引用。

5、                      同时，另外要实现的就是Data与SDO之间的转换以及其他格式的数据与SDO、Data数据之间的数据转换，比如Binary/Xml/Text/Key/文件/等，最基本的是SDO与Data之间的转换，这些转换根据需要，有时候是单向的，有时候是双向的，根据业务需求而定。

6、                      序列化与反序列化，主要是涉及到Binary和XML序列化。对于Binary序列化，倒还是相对好处理点，对INotifyPropertyChanged的处理和ListChanged的处理要多花点心思就可以了。

    [OnDeserialized]
        private void OnDeserialized(StreamingContext context)
        {
            IList<T> list = base.Items;
            for (int i = 0; i < list.Count; i++)
            {
                T t = list[i];
                t.Attach(this);
                SetItem(i, t);
            }
            OnListChanged(new ListChangedEventArgs(ListChangedType.Reset, -1));
            ListChanged += delegate(object sender, ListChangedEventArgs e)                 { OnDataChanged(); };
    }

在反序列化时要重建绑定，并且重新关联事件触发链。因为是不能进行序列化的，我的处理是在此时行了一个投机取巧，请朋友们能给点建议。当然，这只是针对Binary反序列化时有效了。

对于XML的序列化，遇到的问题还要大一些，因为Binary序列化，是对Field进行的，不会影响到事件的触发，也就不会影响到状态的改变，再者也不会引起递归调用了。但是对于微软提供的XML序列化，在此处的应用不能直接的用了，因为XML是对属性的处理，首先，会引起递归调用，其次，事件的触发会引起状态的改变，要对数据进行XML序列化与反序列化，则必须要打破递归调用和取消事件的触发，当然还要提供一些对于XML处理的常用函数了。通常是要实现自定义的对象图序列化反序化，在中间打断递归，对于状态的触发，则要在对象的底层加一特殊处理，阻止事件的触发。不过对于XML序列化反序列化，我还没有实现，上面的只是个思路，不一定正确。主要是因为现在的远程数据走的都是压缩的二进制，当然用的是Binary序列化，要做的是对Binary序列化进行优化。等BS结构提上日程的时候，再对这方面进行处理，会提供一组JS的函数，用于处理绑定、触发的，如果实现的话，则BS的界面也可以实现绑定处理了，只是这是后话了，至少要半年之后。

DTO方面，详细的可以参考Java阵营的SDO，再加上俺们阵营的数据绑定，综合起来，应该差不多了。

我的这个DTO/SDO的实现，已经在两个项目里面已经得到了应用，感觉是大大降低了客户端的代码量、难度、出错概率，配合代码工具，客户端的工作量是成倍的降低了。特别是出错概率，原来的项目，客户端的一个界面通常要调试很多次，而且调试过有不少地方还会出错，现在这方面已经算是非常友好了。在新的项目里面，还升级了的客户端框架，加入了变更通知，就是当关闭窗体的时候，后台判断数据是否改变，给出提示，这个功能是在客户端框架里提供的，编码的时候不会体现出来。这些在后面会慢慢的介绍的。

又写了这么多，希望大家能够共同讨论一下，给俺点建议呀…