问题描述
是否需要控制客户端对DataContract类的实例化。比如说，我创建一个DataContract类叫BO,在实例化一个BO的时候需要执行很多初始化的工作，比较复杂。为了控制这个初始化过程，可以在服务端创建一个IBOFactory的服务接口（包含BOCreate（ClassApara）函数）。先在客户端调用BOCreate（ClassApara），将para信息传给服务端，服务端再进行BO的实例化工作，然后再把实例化的BO传给客户端。但是这样无疑会增加网络的负担，特别是批量创建BO实例的时候。但是如果放在客户端让用户去执行BO实例的创建过程，又容易出现初始化的问题。在服务端执行DataContract的类的对象创建工作，常见吗？该做出那种选择呢？纠结。。。。
解决方案
解决方案二：
自己顶一下是我没有表达清楚问题吗？
解决方案三：
将DataContact的职责进一步分离;
解决方案四：
什么叫做wcf啊？怎么会搞出这类问题？客户端跟服务器端没有什么纠结。就好像你去银行取钱，而人家银行内部为每一个存折建立一本帐。你的客户端就是服务器端的万分之一功能里某一个面向应用的接口的最傻瓜化的文本“代理”。客户端纠结什么服务器端的“初始化”问题？客户端就是一个简单的关于一个实体对象有哪些属性的声明，不应该有任何自以为是（自以为是服务器端功能）的特殊行为。
解决方案五：
一般实体类里面不要有太复杂的方法。太复杂的方法应该作为业务对象独立出来。
解决方案六：
客户端只要忠实地、傻瓜化地把一个功能方法有哪些参数、每一个参数都有哪些属性、属性的类型是什么，简单地反映出来就行了。所以微软的客户端是vs自动化地生成的，编程人员根本不用都此一举去修改它。如果服务器端改变了，你的客户端也想改变（不改变也能用），那么编程人员就使用vs重新更新或者重新引用一下服务器端的地址就行了。有些人自己写什么莫名其妙的机制，而不用vs在几秒钟内就能自动化生成的客户端代理程序。我看不出搞那种所谓的“动态引用服务器”有什么意义？！