.NET世界中的ORM和SOA

11

根据我的经验,对于.NET平台而言,主要的ORM框架(NHibernateLinqToSqlEntity Framework)在跟踪已加载的对象时表现最佳。这在简单的客户端-服务器应用程序中可以很好地工作,但在使用三层或更多层结构以及面向服务的体系结构(Service Oriented Archtitecture)中使用Web服务时,则不可能实现。虽然可以通过自己编写大量跟踪代码来完成这一任务,但ORM是否不应该简化数据库访问呢?

在面向服务的体系结构中使用ORM的想法是否真的可行呢?


你在跟踪方面遇到了什么问题? - Paco
7个回答

7

LLBLGen Pro 带有实体内部的更改跟踪功能。这意味着您可以使用预取路径(因此每个图节点一个查询)从数据库中获取图形,并将其序列化到客户端,更改它,发送回来并直接保存该图形,因为所有更改跟踪都在实体内部(并作为紧凑的自定义元素序列化在XML中)。

免责声明:我是llblgen pro的首席开发人员。


谢谢您的建议,听起来很不错,正是我所需要的。我会尽快查看。 - Rumen Georgiev
从这个播客(http://www.dotnetrocks.com/default.aspx?showNum=451)中我了解到,Entity Framework v4(随VS2010一起发布)也具备这种能力。它允许将其实体序列化到架构的其他层,进行更改,然后将其序列化回原始上下文所在的层,并持久化回数据库。 - Colin Desmond
它能在 Web Farm 环境下实现这个吗?也就是说,在返回的过程中可能会命中不同的服务器? - Rebecca

4
这取决于你所说的“SOA”的含义。在服务契约中暴露域对象很少是良好的服务设计——它会暴露内部实现细节,发布契约存在更大的变更可能性,版本控制也变得非常困难。
如果为您的服务端点创建自定义消息文档(例如 WCF DataContracts),则使用 ORM 实现服务相对容易。通常,您将从数据库重新加载域对象并映射更改的属性(或调用方法),然后持久化更改。
如果您的服务主要是 CRUD 方法,则您的自定义消息将有效地成为 DTO。您需要手动管理乐观并发和域对象映射。
更新:这是一个旧答案,因此我想指出 EF4 现在也 包括实体中的更改跟踪。我仍然认为这是不良的服务契约设计,但如果您只是想要一个分布式应用程序框架,那么它可能是一个不错的选择。

这种方法从SOA的角度来看是不错的,因为它尽可能地保持了合同的简单性。但在保存对象之前进行额外的重新加载会影响性能。如果我们从客户端使用直接的DB访问,我们可以直接调用保存操作。我的想法是通过Web服务实现这种模式。 - Rumen Georgiev
听起来你正在寻找类似ADO.NET数据服务的东西。 我会质疑Web服务层提供的价值是否超过了直接从客户端访问数据库所带来的额外复杂性。双层系统已经不流行了,但是它们更具有性能和更少的代码。 - Sam
我还要指出,SOAP序列化/反序列化有时比多一次查询数据库更成为性能瓶颈 - 如果性能是您的主要目标,请确保进行测量、测量和再测量。 - Sam
哇!SOA,WCF,ORM,CRUD,DTO!我的大脑快要爆炸了... ;) - Lucas Jones

3
请查看DataObjects.Net中即将推出的同步和离线实体POCO和断开连接集合的说明。 链接

2
我谦虚地建议您停止尝试将分布式对象用作架构模式。它不如消息架构或RESTful风格有效。
如果您不喜欢在消息之间传输数据的开销,那么我建议您看看REST。但是,不要像ADO.NET数据服务那样使用REST,那只是通过HTTP进行分布式对象传输。
REST更多地涉及在服务器上公开一个丑陋(但机器可读)的UI,并使用客户端使其美观。在REST中,客户端没有关于域实体的知识,因此您不需要将它们通过网络发送。

1

ORM框架仅在直接与数据库交互时有所帮助。即使在面向服务的体系结构中,ORM也只能帮助减轻编程最终层的负担。您需要其他技术,例如WCF,来处理服务部分。我不知道是否有人已经集成了ORM和服务,但应该很容易地将相同的类注释为实体和DataContract


0

你可以将memcached作为NHibernate的第二级缓存,这是你所说的“跟踪”的意思吗?


0

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接