OR 映射器是否提供异步方法?

发布于 2024-07-13 10:20:21 字数 313 浏览 6 评论 0原文

.Net O/R(对象/关系)映射器是否提供开箱即用的异步方法?

如果可能的话,我不想为异步方法编写样板,

我已经使用 CCR 框架使用异步方法推出了自己的 DAL。 CCR 基本上要求我不要阻塞任何等待 IO 响应的线程。

到目前为止,我的解决方案的好处是它已降至最低限度。 但随着这个项目的规模和功能不断增长,我面临着维护原始 SQL 查询和样板代码的艰巨任务。

但另一方面,如果 O/R 映射器异步方法实际上只是一个混乱的黑客,增加了奇怪的复杂性,我的情况也不会更好。

请不要关注异步编程的替代方案。

Do any .Net O/R (object/Relational) Mappers provide Asynchronous methods out of the box?

I don't want to have to write the boiler plate for the asynchronous method if possible

I have rolled my own DAL with Asynchronous methods using the CCR framework.
The CCR basically demands that I don't block any of it's threads waiting for IO responses.

The good part about my solution so far is that it is down to the bare minimum. But as this project grows in terms of scale and functionality, I am facing the mildly daunting task of maintaining raw SQL queries and boiler plate code.

BUT on the other hand if the O/R mapper Asynchronous methods are really just a messy hack that adds oddles of complexity I am not better off.

Please don't focus on alternatives to Asynchronous programming.

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

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

发布评论

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

评论(6

不语却知心 2024-07-20 10:20:21

是的,对于 SQLAlchemy(最好的 ORM 之一),有 sAsync:

http://foss.eepatents.com/ sAsync

和 NADBAPI:

http://developer.berlios.de/projects/nadbapi/< /a>

Yes, for SQLAlchemy (one of the best ORMs), there is sAsync:

http://foss.eepatents.com/sAsync

and NADBAPI:

http://developer.berlios.de/projects/nadbapi/

画中仙 2024-07-20 10:20:21

我认为你搞错了。 我的理解是,在您的情况下,异步执行应该在架构级别处理,而不是 ORM 级别,即消息队列驱动架构。 我看到的是,您的网络服务器只会将消息放入队列中,并且有某种后台代理在队列之外进行异步处理。

由于我没有足够的声誉来发表评论,并且 Stackoverflow 提醒我插入另一个“答案”,我将在这里留下我的评论。

Lee B:SQLAlchemy? 你如何将它与.NET一起使用???

I think you got it wrong. My understanding is that asynchronous execution in your case should be handled at architecture level instead of ORM level i.e. message queue driven architecture. What I see is that your webserive will only place a message in the queue and there is some kind of background agent does the asynchronous processing off the queue.

Since I don't have enough reputation to comment and Stackoverflow is alerting me inserting another "answer" I will leave my comment here.

Lee B: SQLAlchemy? How do you use it with .NET???

二手情话 2024-07-20 10:20:21

虽然我不确定他们中的任何一个是否可以开箱即用,但您可以使用 .NetTiers,这是基于模板。 您只需将异步部分添加到模板即可。 这至少可以消除您维护样板代码和裸 SQL 查询的麻烦。 此博客 展示了如何向 MS Enterprise 库添加异步调用(如果您选择,.NetTiers 可以使用该库)。

截至 2008 年 12 月中旬,LLBLGen Pro 本身并不支持异步调用。 目前 Genome 也没有。 Telerik 似乎也没有这样做。 几乎只是搜索了他们的文档并寻找 async 或以 begin 开头的方法,因为这就是模式。

我让其他答案来讨论这是否是一个好主意......

While I'm not sure if any of them do it out of the box, you could use .NetTiers, which is template based. You could just add the async parts to the template. That would at least eliminate you having to maintain the boilerplate code and bare SQL queries. This blog shows how to add async calls to the MS Enterprise library (which .NetTiers can use if you choose).

As of mid-December 2008, LLBLGen Pro does not natively support async calls. Currently Genome doesn't either. It doesn't appear that Telerik does either. Pretty much just searched their documentation and looked for either async or methods that start with begin because that's the pattern.

I let the other answers speak as to if it's a good idea or not...

谁许谁一生繁华 2024-07-20 10:20:21

以异步方式获取数据可以通过多种方式完成。 将其外包给 o/r 映射器会带来您可能不想处理的挑战,因为它并没有真正使您的代码变得不那么复杂。 主要问题是您必须有一种机制,当 o/r 映射器完成获取时会收到通知,以便通知调用者数据已准备好。

这并不比您自己创建线程并从该线程调用 o/r 映射器的获取逻辑复杂。

当您声明要创建一个应该响应的 Web 服务时,您必须意识到调用者位于 Web 服务之外并等待数据。 Iow:如果调用者使用 Web 服务来获取数据,那么它已经是异步的,因为其他客户端仍然可以调用 Web 服务:原始调用者的请求在不同的线程上处理,获取数据的逻辑在该线程内运行线程,然后将数据返回给调用者。

使用异步方法在这里是没有用的,因为否则必须在数据准备好时通知调用者,这需要从 Web 服务向客户端推送,这要求客户端只要获取数据就保持与 Web 服务的连接无论如何。

异步数据库交互并不是什么神奇的东西,你可以扔给某样东西,让它变得更快响应。 异步数据库交互可以使调用者同时做其他事情。 但是,如果这已经不是必需的,那么您就不需要异步数据库交互,这将使您的代码变得不那么复杂。

Fetching data in an asynchronous way can be accomplished in various ways. To outsource it to an o/r mapper gives challenges which you probably don't want to deal with as it doesn't really make your code less complex. The main problem is that you have to have a mechanism which is notified when the fetch is completed by the o/r mapper, so the caller is notified that data is ready.

This isn't less complex than creating a thread yourself and call the o/r mapper's fetch logic from that thread.

As you state that you want to create a webservice which should be responsive, you've to realize that the caller is outside the webservice and waits for data. I.o.w.: if the caller uses the webservice for fetching data, it's already asynchronous, as other clients will still be able to call the webservice as well: the original caller's request is handled on a different thread, logic to fetch the data is ran inside that thread, and the data is then returned to the caller.

Using asynchronous methods is of no use here, as the caller would otherwise have to be notified when the data is ready, which requires a push from the webservice to the client, which requires the client to stay connected to the webservice as long as the fetch takes anyway.

Asynchronous db interaction isn't magic things you can throw at something so it gets more responsive. Asynchronous db interaction could make the caller do other things in the mean time. However if that's already not necessary, you don't need asynchronous db interaction to begin with, which will make your code a lot less complex.

蘑菇王子 2024-07-20 10:20:21

Nhibernate 似乎比 LinqToSQL 更容易实现 Async。 请参阅

就我个人而言,我会做的是使用我的很满意(因为我没有使用过 NHibernate,所以我会担心学习曲线和潜在问题,所以我宁愿使用 LINQtoSQL 或定制数据访问层之类的东西)并将其包装在它自己的 Web 服务中 WCF LOB 适配器

如果您确实不想自己编写代码,则可以使用 ADO.NET数据服务 基本上为实体框架执行此操作。

Nhibernate seems to be relatively easier to implement Async than LinqToSQL. See this

Personally what I would do though is use what I am comfortable with (as I haven't used NHibernate I would worry about the learning curve and potential issues so I would rather use something like LINQtoSQL or bespoke data access layer) and wrap it in it's own web service of WCF LOB Adapter.

If you really didn't want to code that yourself you could just use ADO.NET Data Services which does basically that for the Entity Framework.

待天淡蓝洁白时 2024-07-20 10:20:21

听起来您缺少一些索引。

或者你需要将数据库设计转向OLAP模型。

如果不是这样的话。

  1. 获取更多内存。
  2. 获得更多的CPU。
  3. 对表进行分区。
  4. 在数据库前面构建一个可以处理异步请求的包装器。 它看起来像一个队列。

It sounds like you are missing some indexes.

Or you need to shift database design to OLAP model.

If that is not the case.

  1. Get more ram.
  2. Get more CPU.
  3. Partition your tables.
  4. Build a wrapper infront of the DB that can handle async requests. It will look like a queue.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文