如何在RIA域服务中调用除CRUD以外的操作?

发布于 2024-08-20 12:34:24 字数 1581 浏览 4 评论 0原文

我很难理解如何在 RIA 服务的域服务中实现更复杂的操作。这就是 Beta 2 中的所有 Silverlight 4、VS 2010 和 .Net Framework 4。

目标

我希望可以在 LinqToEntitiesDomainService 上创建一个操作,该操作将具有如下签名:

public UnwieldyOperationResult PerformUnwieldyOperation( UnwieldyOperationParameters p );

这个想法是该操作采用参数集合并执行相当复杂的操作,将更新实体的不同实例和类型,否则通过 DomainService CRUD 功能进行操作。

问题

我遇到的直接问题是似乎不允许将自定义类型作为参数传递给方法,并且我认为沿着这些路线的某些内容会用于返回值。为了清楚起见,我想将操作参数封装在 DTO 中,而这个笨重的操作在我用 Entity Framework 4.0 模型封装的遗留数据库中没有任何对应的实体,而我又将域服务基于该模型。

域服务是否应该只处理底层 EF 模型中的实体类型?它不是旨在公开像我的 UnwieldyOperation 这样更复杂的操作吗?

如果是这样,我可以以某种方式构建另一个允许操作签名和操作实体框架的服务吗?

我知道只有一个域服务可以处理模型中的实体。这导致我将所有 CRUD 以及现在的 UnwieldyOperation 塞进一个域服务中,尽管我的第一个想法是将服务拆分为更小的部分。

如果我想让操作在域服务中使用参数和返回值,我的下一个愿望是让客户端刷新域上下文中已加载的实体。

对于这样的事情有什么有效的机制吗?

你打算怎么做呢?

到目前为止我所拥有的......

简而言之,这就是我到目前为止所拥有的:

  • 我已经包装了一个现有的遗留数据库 使用 Entity Framework 4.0 模型作为 少量额外的填充/代码为 可能的。这意味着右键单击、添加并从数据库生成。

  • 我已经在 DomainService 中实现了更简单的 CRUD 操作,并且我成功地使用它们来显示和编辑直接数据。我通过客户端中的 ViewModel 对逻辑进行了一些封装,但我直接公开了实体类,但我认为这与我的问题无关。

  • 我意识到我无法像我最初想象的那样以直接的方式添加 UnwieldyOperation...而且我怀疑/希望我误解了域服务机制的某些方面,这导致我目前的情况。

有一种方法可以走吗?

在这样的问题中写下这一点让我想到也许我会朝这个方向发展:

  1. LegacyModelService 公开 CRUD 操作,就像我已经完成的那样。
  2. 在另一个服务中暴露笨重的操作。我应该将其设为 RIA Doamin 服务还是只是普通的 WCF?
  3. 从新的 UnwieldyOperationsService 访问实体框架模型并在那里操作数据层。
  4. 在客户端显式重新加载或刷新 LegacyModelService 的客户端域上下文,以反映 UnwieldyOperation 可能导致的更改。完成这件事的好方法是什么?

I have some trouble getting my head around how to implement more complex operations in a Domain Service in RIA Services. This is all Silverlight 4, VS 2010 and .Net Framework 4 in Beta 2.

Goal

I wish I could create an operation on my LinqToEntitiesDomainService that would have a signature something like this:

public UnwieldyOperationResult PerformUnwieldyOperation( UnwieldyOperationParameters p );

The idea is that this operation takes a colleciton of parameters and performs rather complex operations which would update different instances and types of the entities that are otherwise manipulated through the DomainService CRUD functionality.

Problem

The immediate problem i hit is that does not seem to be allowed to pass the custom type as parameter to the method, and I suppose something along those lines go for the return value. I want to encapsulate the operation parameters in a DTO for clarity, and this unwieldy operation does not have any corresponding entity in the legacy database that I have wrapped with Entity Framework 4.0 model, which I am in turn basing the Domain Service on.

Is a domain service supposed to deal with only the types that are entities in the underlying EF model? Is it not designed to expose more complex operations like my UnwieldyOperation?

If so, can I build another service somehow that allows both the operation signature and to manipulate the entity framework?

I have understood that only one Domain Service can handle an entity from the model. This has led me to cram all the CRUD and now also the UnwieldyOperation into one Domain Service, although my first idea was to split the service into smaller parts.

If I'd get the operation to work with parameters and return value in the Domain Service, my next wish would be to have the entities that are already loaded in the domain context at the client refresh themselves.

Is there any efficient mechanism for such a thing?

How would you go about to do that?

What I have so far...

In short, this is what I have so far:

  • I have wrapped an existing legacy database
    with an Entity Framework 4.0 model with as
    little extra padding/code as
    possible. This means right-click, add and generate from database.

  • I have implemented the simpler CRUD operations in the DomainService and I am using them successfully to display and edit straight forward data. I have some encapsulation of logic through ViewModels in client but I expose the Entity classes directly, but I think this is unrelated to my problem/question.

  • I have realized that I can't add the UnwieldyOperation in an as straight forward manner as I initially thought... Also I suspect/hope that I have misunderstood some aspects of the Domain Service mechanism, which has led me to the current situation.

One way to go?

Writing this down in a question like this gives me the idea that perhaps I'd go in this direction:

  1. LegacyModelService expose the CRUD operations as I have already done.
  2. Expose the Unwieldy operations in another service. Should I make that a RIA Doamin Service or just plain WCF?
  3. Access the Entity Framework model from the new UnwieldyOperationsService and manipulate the data layer there.
  4. Explicitly reload or refresh the client domain context for the LegacyModelService at the client to reflect the changes that may have resultet from the UnwieldyOperation. What would be a good way get this done?

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

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

发布评论

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

评论(1

葮薆情 2024-08-27 12:34:25

查看 http://msdn.microsoft.com/ en-us/library/ee707373%28VS.91%29.aspx 对于简单 CRUD 之上的命名约定,也许调用或命名更新操作会合适?

Check out http://msdn.microsoft.com/en-us/library/ee707373%28VS.91%29.aspx for naming conventions over and above simple CRUD, maybe Invoke or Named Update operations would be suitable?

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