用于传输非 DB 对象图的 RIA 服务
我一直在研究 RIA 服务，因为我认为它可以简化我希望构建的 Web 应用程序的服务层的处理。我看到很多示例展示了如何创建 DomainService 类，这些类公开和使用具有某种关系数据库支持的实体，因此具有外键关系。但是，我想知道如何公开和使用普通对象图...包含彼此引用但没有外键的对象。
例如，假设我想要一个名为“GetFolderInformation(string pathToFolder)”的服务操作。我希望它返回一个名为“FolderInformation”的自定义对象，其结构如下：
- string Name
- IEnumerable<FileInformation> Files
我无法使其工作，因为 RIA 似乎想要处理具有外键关系的实体。为什么？为什么序列化程序不能只看到我的对象引用并在另一端的代理中重新创建它？
数据存在于服务层后面，不一定具有外键关系......例如文件夹/文件。
编辑：我意识到我没有问我的问题！我的问题是，有办法做我想做的事吗？
I have been getting into RIA services because I thought it would simplify dealing with the services layer of web applications I wish to build. I see lots of examples out there showing how to create DomainService classes which expose and consume entities that have some kind of relational database backing, and therefore have foreign-key relationships. However, I would like to know how to expose and consume normal object graphs...objects that contain references to eachother but don't have foreign keys.
For example, say I want a service operation called "GetFolderInformation(string pathToFolder)". I want this to return a custom object called "FolderInformation" structured with:
- string Name
- IEnumerable<FileInformation> Files
I cannot get this to work because it seems that RIA wants to deal with entities that have foreign key relationships. Why? Why can't the serializer just see my object references and recreate that in the proxy on the other side?
Data exists behind service layers that doesn't necessarily have foreign key relationships...like folder/file for example.
EDIT: I realized I hadn't asked my question! My question is, is there a way to do what I am trying to do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这（复杂类型、与实体关联无关的对象图）是我们想要的，但没有进入 v1。
这是因为需要处理的不仅仅是序列化，这可能是该场景中最简单的部分。更多涉及的是支持更改通知、跟踪、撤消等的代码生成客户端类型。
有多种解决方法。通常涉及在边界上展平并根据展平的数据集在另一侧重新创建图形。尽管在技术上是可行的，但应用程序代码中并不一定简单。
This (complex types, object graphs that aren't about entity associations) is something we want, but didn't make the cut for v1.
This is because there is a lot more than seralization to handle, which is perhaps the simplest part of the scenario. More involved is code-gen'ing client types that support change notification, tracking, undo, etc. etc.
There are ways to workaround. Generally involves flattening on the boundary and recreating a graph on the other side from flattened set of data. It's not necessarily straightforward in app code, even though techically possible.