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

[cxx1997]

我们希望实现一个可以远程部署（包括外网）的三层架构
为了实现复杂的客户端操作，展现层使用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号结贴，到时不管有没有答案，都谢谢大家

[lwl0376]

关注

[renzhe02]

关注

[yinxing2012]

看书去。！

[crossrowman]

m

[犀牛老爹]

先占个沙发

[Koala_sea]

mark

[deer_box]

友情关注

[honey52570]

up

[Eddie005]

个人认为没必要强求所谓的“业务层真正独立”

相对来说大量地使用反射是偶最不能接受的

[cxx1997]

业务层真正独立 我觉得好处有
1：维护更方便 当业务逻辑有部分调整时，可以只需要重新部署业务层
2：在业务层上做数据缓存，降低对数据库的依赖
3：可以发展成独立的子系统

[stning]

这个是要实现分布式的吗？这个问题要考虑的东西很多啊

[honey52570]

学习

[xh831213]

个人认为，其实程序的分层就是使程序的条理性和可读性提高了
很难把表现层和业务逻辑层完全隔离
我就不信，你的业务逻辑都变了，表现层会不变

所以，分3层也好，2层也罢，只是程序的结构问题

[hgs5945]

可以考虑用webservices呀!

[qinhl99]

一个好的帖子,先帮着顶起来,有时间在细研究!

[w_zrong]

我爱你

[lovvver]

业务层完全独立，有挑战。
关注一下先。

[kbryant]

好贴子一定要顶，关注中。。。

[kbryant]

希望搂住早日解决问题

[budong0000]

mark..