假设某公司有若干个主要由ASP.net构建的系统(包括网站——如果把网站也看成是系统的话)，每个系统都实现与公司某方面业务相关的功能。比如库存商品维护，员工信息维护，企业网站，日常报表，发货单打印与维护等等等。这些系统彼此之间相对独立，但企业的核心数据都集中保存在1-2个SQL Server数据库中。问题是，如果架构能够有效地应对业务逻辑的变更，比如当定价策略发生变化时，相应的系统(比如网站上的产品介绍，发货单打印，库存商品信息)尽可能不做修改，而应对此类变化。简单说，就是如何在各系统中只实现界面呈现，而将几乎所有的业务逻辑封装到一起，供各个子系统调用。我想到的两个方案：
方案1.建立一个公共类库，将Entity，Data Access Layer, Business Logic Layer都封装到这个类库里，各个子系统中只引用这些类库。这样做虽然可以将业务逻辑集中，但带来的问题也不小：
i) 业务逻辑的变更很可能导致函数的参数类型发生变化，如果函数的参数发生变化，还是需要更新每个系统中相应的代码；
ii) 即使参数不做修改，只有函数内部得逻辑发生变化，那么每次核心类库重新编译过后，各个子系统还是要重新编译。或者至少要将编译过后的核心类库dll重新部署到各个子系统的Web服务器上的bin目录中，对于同时运行几十个系统的状况来说，很不可取方案2. 建立一整套WebService，所有业务对象的数据和操作通过WebService完成。这种想法貌似比方案1好些，但也有问题:
i) 还是参数变化的问题，如果参数变化，作为调用Webservice的各个系统依然需要更新调用Webservice的代码
ii) Webservice在大量数据(如几百条以上记录的表)和不能很好地序列化的数据类型面前有些力不从心。不知道有没有朋友面临同样的问题，有什么办法解决。欢迎交流探讨。
方案1.建立一个公共类库，将Entity，Data Access Layer, Business Logic Layer都封装到这个类库里，各个子系统中只引用这些类库。这样做虽然可以将业务逻辑集中，但带来的问题也不小：
i) 业务逻辑的变更很可能导致函数的参数类型发生变化，如果函数的参数发生变化，还是需要更新每个系统中相应的代码；
ii) 即使参数不做修改，只有函数内部得逻辑发生变化，那么每次核心类库重新编译过后，各个子系统还是要重新编译。或者至少要将编译过后的核心类库dll重新部署到各个子系统的Web服务器上的bin目录中，对于同时运行几十个系统的状况来说，很不可取方案2. 建立一整套WebService，所有业务对象的数据和操作通过WebService完成。这种想法貌似比方案1好些，但也有问题:
i) 还是参数变化的问题，如果参数变化，作为调用Webservice的各个系统依然需要更新调用Webservice的代码
ii) Webservice在大量数据(如几百条以上记录的表)和不能很好地序列化的数据类型面前有些力不从心。不知道有没有朋友面临同样的问题，有什么办法解决。欢迎交流探讨。
是不是可以配置参数，写在xml或数据库
Class Item
Public Shared Function ItemPrice( _
ByVal CustomerType As String _
) As Decimal
......
End Funtion
End Class
某天企业定价策略变了，不单单考虑客户类型，还要考虑客户所在的地域，那么核心类库需要改变/抑或重载为:
Public Item
Public Shared Function ItemPrice( _
ByVal CustomerType As String, _
ByVal Location As String) As Decimal
......
End Funtion
End Function那么，在所有子系统中，以前返回价格的代码类似Item.ItemPrice("102C")都要相应地变成Item.ItemPrice("102C", "BEIJING")我要面对的不是参数值的变化，而是参数类型或数量的变化。
===========
你的意思是说客户端随着ws的改变得重新改变了?如果这样的话，那必须重新编译各个客户端了。
如果只变服务端，可考虑重载之类的
======
WCF 不知道会不会好点，没测试过.但传输的数据量可以设置的。
两个方案都有可取之处.看实际开发
多个子系统多个DLL.动某一个DLL不会影响其它子系统..
主要看你自己的对整个的架构是否清晰..WEB服务..你可以说数据量大的时候慢..但你真正用到的时候可能就和数据量没有关系了..
像你所说到的大型企业系统设计，框架是最重要与最先考虑的问题。其中接口与虚拟类的运用是十分重要。
你必须先确定框架的结构，然后再设计实现类型。而像你所说的参数类型，参数个数的变化应该尽量避免。如果真的要转变的话，则可应用 WEB SERVCIE来解决问题。（现今Ajax技术中正提倡面向服务设计）
比如说在客户端是调用 http://.../*.asmx?Id=0来获取数据，使数据以XML或JOSN方式传递。则它不需要理会服务器部分是应用什么方式来取得数据。
这样，则可实现业务层与表现层的分离。在你服务器系统架构发生改变时,避免页面重新设计。特别是你所说企业系统已经超越ASP.NET，而应该以“分布式编程”的形式去完成的。这时候这个SOA好处特别明显。
之所有我推荐类库接口，是因为web service是跨进程的，调试起来一定没有本地的类库来得方便。其实类库和web service对于接口的变更的工作量是一样的，但整体来说，web service的工作量会大一些。
比如说现在计算机的usb接口改变了，那么可想而知。
重点是在客户端定义好自己的接口
方案一的做法, 其实是把所有系统都集合为一个系统了, 而你这个集合起来的"大"系统又是分开安装到若干台服务器或者目录中, 情况比较复杂, 是会面对重新发布DLL的问题; 我觉得方案二的思路反而可以参考, 不过不是说WebService可取.
你的系统是完成各自的业务, 所以不能等同把它们看做一个大系统, 而是互相配合的若干系统, 这样你的难度会降低一些. 系统之间可以考虑类似WebService进行数据交换,毕竟各个系统之间进行百万级别的数据同步, 可能性还是小一些(主要是考虑数据是同步修改的, A系统的数据修改即时通知B系统进行更改).
其实, 还是系统架构中对于业务功能的划分问题, 而不是简单的发布DLL的问题.
对于你说的问题确实是个比较棘手的。现在大家都对soa的解决方案有着很深的认识，但是不知道你们有没有想过soa的解决方案前提是系统的高度的集成和松耦性。
webservice有优点那是在调用服务方面，但是依据你当前的系统给人的感觉是不合适宜的。与其那样，倒不如把系统中不同业务做成接口，然后来调用，这样兴许能解决问题，就好像金融行业的解决方案ieee一样。这个也只是我的想法，如有不对的地方还请大家指正。