我是一名学生,目前正在使用Nhibernate + WCF + WPF的.Net n层应用程序.
其中一件非常糟糕的事情是对象图序列化,事实上它根本没有完成,目前关联被忽略,我们在各处使用DTO.
据我所知,一个方法可以预先定义哪些对象和集合应该被加载和序列化以便通过网络传递,从而能够向客户端呈现一些关联,但是这看起来有限,不灵活且不一致(你能吗？)告诉我,我不喜欢这个想法).
我遇到的一个选择是简单地用客户端层上的延迟负载集合替换NHProxies,其中"disconnectedProxy"将通过线路检索相关的东西.这意味着我们必须稍微扩展我们的Web服务签名并对我们生成的代理做一些hackery,但这似乎是一个很好的T4 /其他代码生成实验.
据我所知,这似乎是一个常见的绊脚石,但经过大量的阅读后,我无法找出任何好的/普遍接受的解决方案.我正在寻找与任何特定解决方案一样多的方向,但如果有一种简单的方法让客户"感觉"连接,请告诉我.
你问一个非常好的问题,遗憾的是没有一个非常干净的答案.即使您能够通过WCF进行延迟加载(我们能够做到),您仍然会遇到使用代理拦截器的问题.相信我,你想要客户端层上的POCO对象!
你真正需要考虑的是......从我所见过的研究中被认为是这个问题的行业标准方法,被称为持久性与使用或持久性无知.换句话说,您的对象模型和映射表示您的持久性域,但它与您的理想使用方案不匹配.你不想把整个数据库带到客户端只是为了显示几个属性吗？
这似乎是一个简单的问题,但解决方案要么非常简单,要么非常复杂.一方面,您可以围绕使用场景设计实体,但最终会导致对象域的扩散,从而难以维护.另一方面,您仍然需要富对象模型关系才能编写精细的业务逻辑.
为了简化这个问题,我们来看看我们需要填补数据库和数据库/服务层之间以及服务到客户端差距的两个主要差距.NHibernate通过提供ORM将数据加载到对象中来填充第一个.它做得不错,但为了获得出色的性能,需要使用自定义加载策略进行调整.我离题了......
服务器和客户端之间的第二个差距是事情变得冒险.为了简化,假设您没有通过网络将任何映射实体发送到客户端？尝试创建一种机制,将业务实体交换为DTO对象,同样将DTO对象交换为业务实体.这样,您的客户只处理DTO(当然是POCO),您的业务逻辑可以保持其丰富的结构.这使您不仅可以利用NHibernate的延迟加载机制,还可以利用会话的其他好处,例如L1缓存.
出于简洁和知识产权的原因,我不会进入上述机制的设计,但希望这足以指出您正确的方向.如果你根本不关心性能或延迟......只需将延迟加载一起关闭并完成序列化问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 