三层架构下的设计问题（12月12号结贴，欢迎大家来讨论）

Question

我们希望实现一个可以远程部署（包括外网）的三层架构
为了实现复杂的客户端操作，展现层使用WIN FROM
中间业务层使用了CASTLE+NH做ORM
数据访问层 NH的数据访问模块现在如果是普通的CS模式，已经没有问题
但是如果要部署成三层架构，我想到两个方案
1：部署数据访问层
实现一个可透过HTTP/TCP等协议访问的数据访问方式，然后插入NH这个方案从设计理念上讲，展现层和业务层还是耦合在一起的，业务层没有真正独立2：部署业务层
由于CASTLE的实体类包含了对象的数据和操作，且没有继承MASHBYREF，只实现了序列化，意味着我们可以把实体类传递到展现层，但无法使用实体类的方法（如SAVE、CREATE等）
我查询了一些资料后，觉得有三个选择
1：修改CASTLE代码，使其基类继承MASHBYREF，然后透过REMOTING发布，展现层以CAO模式使用这个方案，感觉风险很大，CREATE都是透过反射NH来做的，这样部署是否有风险2：实现自己的实体类和操作类，实体类只包含数据，操作类为无状态服务层
操作类透过REMOTING以SINGLECALL方式发布，内部实现上，将传递来的实体类转换为CASTLE的类，然后调用或反射CASTLE的相应方法这个方案，工作量不小，层层反射后，效率很低；实体类的关系处理变得复杂，
CASTLE的很多特性无法使用（比如其中一个属性延迟加载）；3：网上有人提到可以用CASTLE的AOP，在前台扑捉实体类的操作后，反射到远程服务器觉得这个方案和2方案的本质差不多，可以少写点代码是可能的
欢迎大家提出建议
我将在12月12号结贴，到时不管有没有答案，都谢谢大家

Answer 1

明显第二种的好。
我是觉得实体类本来就不应该有Save、Create这些方法，难道脱离了数据库实体类就无法存在了？
如果觉得反射效率太低的话，用代码生成器比较好。

Answer 2

NH.net做orm不是也行吗？castle是有一些不方便的地方，但是你说的这3种方案好像除了第1种工作量都很大啊，而且有很多没必要套用架构地，

Answer 3

看来问题很大程度上是因为CASTLE把对象的数据定义和操作放在一起了直接用NH的话，就分的比较清楚了

Answer 4

这种情况下使用Web Service是你的最好选择。win form >> web service  >> BLL >> NH DataAccess这样可令你的架构更为健壮。如果你的代码真正使用的是面向对象的设计与编程模式，
在Logic三层架构向物理架构转换的时候加入一个由web Serivice实现的Facade 层将会是一件非常容易而且有意义的事情。