尝试确定 NHibernate 或其他任何东西是否适用于访问 Web 服务

发布于 2024-09-10 08:43:49 字数 311 浏览 2 评论 0原文

情况是这样的。

我们有一个第三方中间件(使用 SQLServer 作为后端),我们使用 HTTP 服务链接和类似 XMLRPC 的消息传递与其进行通信。

该服务始终返回数据集作为任何返回内容的命令的结果。有一种方法可以将嵌入式 SQL 语句传递给服务。

因此,我们无法直接访问数据库。

我正在尝试使用一个可以简化访问的层来隔离此服务。我正在考虑使用像 NHibernate 这样的 ORM。

NHibernate 支持这种情况还是 NH 总是需要直接访问数据库?

如果您有任何其他建议,我会洗耳恭听......

Here's the situation.

We have a 3rd party middleware (using SQLServer as a back-end) which we communicate with using an HTTP service link and XMLRPC-like messaging.

The service always returns a dataset as results of any commands that returns something. There is a way to pass an embedded SQL statement to the service.

So, we do not have a direct access to the database.

I'm trying to isolate this service with a layer that would simplify access. I was thinking of using an ORM like NHibernate.

Is this scenario supported by NHibernate or does NH always needs a direct access to the database?

If you have any other suggestions I'm all ears open...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

夜光 2024-09-17 08:43:50

如果我理解正确的话,你被迫使用第 3 方中间件 - 但这并不容易处理?

我从未使用过 NHibernate,所以我不能对此发表评论。

听起来你想在顶部添加一个新的“服务层”(因为需要一个更好的术语),这样更容易处理; 外观模式立刻浮现在脑海中(尽管它经常被用来捆绑各种不同的、不同的单个内聚集成点下的接口)。

基本上,您想要定义一组干净的接口/服务(在新的服务层中);然后,这个新层将完成与中间件交互的所有艰苦工作 - 或者如果有机会的话,直接与数据库交互。

我还建议将这个新层分成几个子部分:您不想去构建一个与中间件(或数据库)紧密耦合的新层 - 使用 依赖注入将外部外观与具体实现隔离,并维护松散耦合。这样,即使中间件消失,您也不会直接影响您所构建的新服务层的消费者。

最后,在设计新的面向外部的服务时,请牢记接口隔离原则 (ISP)。

免费图片托管 http://www.freeimagehosting.net/uploads/89e5a8a47a.jpg
此处为全尺寸图片

If I understand you correctly, you're forced to use the 3rd party middle-ware - but it's not easy to deal with?

I've never used NHibernate so I can't speak for that.

Sounds like you want to add a new "service layer" (for want of a better term) on the top that's easier to deal with; the Facade pattern leaps to mind (although that's often used to bundle up a variety of different and disparate interfaces underneath a single cohesive integration point).

Basically you want to define a nice clean set of interfaces / services (in the new service layer); this new layer will then do all the hard work of interacting with the middle-ware - or with the database directly if you get the chance.

I would also suggest making this new layer into a couple of sub-parts: you don't want to go and build a new layer that's tightly coupled to the middle-ware (or database) - use Dependency Injection to isolate the outer facade from the concrete implementation, and maintain loose coupling. That way if the middle-ware disappears you won't directly impact consumers of the new service layer you've built.

Lastly, keep the Interface Segregation Principle (ISP) in mind when designing the new externally facing services.

Free Image Hosting http://www.freeimagehosting.net/uploads/89e5a8a47a.jpg
(Full size image here)

请持续率性 2024-09-17 08:43:50

我们使用 NHibernate,但它很糟糕。我不会推荐它做任何事情。据我所知,NHibernate 确实需要直接访问数据库(或者至少您只需为 NHibernate 提供一个连接字符串,就像任何其他数据访问提供程序一样)。另外,正因为如此,我很确定它不知道如何处理 Xml 数据集。

We use NHibernate and it sucks. I would not recommend it for anything. As for as I know, NHibernate does require direct access to the database (or at least you just give NHibernate a connection string like you would any other data access provider). Also, because of that, I'm pretty sure it won't know how to handle Xml datasets.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文