如何让 RIA 服务返回的集合 CanAddNew 为 true
RIA 服务正在返回不允许我添加新项目的实体列表。以下是我认为相关的详细信息:
- 我正在使用 2010 年 4 月中旬发布的 Silverlight 4 和 RIA Services 1.0 版本。
- 我有一个 DomainService,其查询方法返回
List
< /代码>。 - ParentObject 包括一个名为“Children”的属性,其定义为
List
。 - 在 DomainService 中,我为 ParentObject 定义了 CRUD 方法,并为查询、删除、插入和更新功能提供了适当的属性。
- ParentObject 类有一个用 [Key] 属性标记的 Id 属性。它还具有用属性 [Ininclude]、[Composition] 和 [Association("Parent_Child", "Id", “ParentId”)]。
- ChildObject 类有一个用 [Key] 属性标记的 Id 以及一个包含父级 Id 的外键“ParentId”。
在客户端,数据成功返回,我将查询结果分配给 PagedCollectionView,如下所示:
_pagedCollectionView = new PagedCollectionView(loadOperation.Entities);
当我尝试将新的 ParentObject 添加到 PagedCollectionView 时,如下所示:
ParentObject newParentObject = (ParentObject)_pagedCollectionView.AddNew();
我收到以下错误:
“ '添加新'不是允许这种观点。”
经过进一步调查,我发现 _pagedCollectionView.CanAddNew 为“false”并且无法更改,因为该属性是只读的。
我需要能够向 PagedCollectionView 添加和编辑 ParentObjects(当然还有其相关的子对象)。我需要做什么?
RIA Services is returning a list of Entities that won't allow me to add new items. Here are what I believe to be the pertinent details:
- I'm using the released versions of Silverlight 4 and RIA Services 1.0 from mid-April of 2010.
- I have a DomainService with a query method that returns
List<ParentObject>
. - ParentObject includes a property called "Children" that is defined as
List<ChildObject>
. - In the DomainService I have defined CRUD methods for ParentObject with appropriate attributes for the Query, Delete, Insert, and Update functions.
- The ParentObject class has an Id property marked with the [Key] attribute. It also has the "Children" property marked with the attributes [Include], [Composition], and [Association("Parent_Child", "Id",
"ParentId")]. - The ChildObject class has an Id marked with the [Key] attribute as well as a foreign key, "ParentId", that contains the Id of the parent.
On the client side, data is successfully returned and I assign the results of the query to a PagedCollectionView like this:
_pagedCollectionView = new PagedCollectionView(loadOperation.Entities);
When I try to add a new ParentObject to the PagedCollectionView like this:
ParentObject newParentObject = (ParentObject)_pagedCollectionView.AddNew();
I get the following error:
" 'Add New' is not allowed for this view."
On further investigation, I found that _pagedCollectionView.CanAddNew is "false" and cannot be changed because the property is read-only.
I need to be able to add and edit ParentObjects (with their related children, of course) to the PagedCollectionView. What do I need to do?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我昨天刚刚尝试了一个解决方案,对它的工作原理感觉非常好。您无法添加的原因是源集合(op.Entities)是只读的。但是,即使您可以添加到集合中,您仍然希望添加到 EntitySet 中。我创建了一个中间集合来为我处理这两件事。
然后,我在这样的代码中使用它。
唯一需要注意的是该集合不会主动更新 EntitySet。不过,如果您绑定到 op.Entities,我认为这就是您所期望的。
[编辑]
第二个警告是这种类型是为装订而设计的。为了充分利用可用的列表操作(清除等),您还需要重写一些其他方法来进行写入。
我计划写一篇文章来更深入地解释这一点,但现在,我希望这已经足够了。
凯尔
I was just playing around with a solution yesterday and feel pretty good about how it works. The reason you can't add is the source collection (op.Entities) is read-only. However, even if you could add to the collection, you'd still want to be adding to the EntitySet as well. I created a intermediate collection that takes care of both these things for me.
Then, I use it in code like this.
The only caveat is this collection does not actively update off the EntitySet. If you were binding to op.Entities, though, I assume that's what you'd expect.
[Edit]
A second caveat is this type is designed for binding. For full use of the available List operation (Clear, etc), you'd need to override a few of the other methods to write-though as well.
I'm planning to put together a post that explains this a little more in-depth, but for now, I hope this is enough.
Kyle
这是我正在使用的解决方法:
您可以在 DomainContext 上检索 EntitySet,而不是使用 AddNew。通过说 Context.EntityNamePlural (即: Context.Users = EntitySet)
您可以通过调用 Add() 向该 EntitySet 添加新实体,然后调用 Context.SubmitChanges() 将其发送到数据库。为了反映客户端上的更改,您需要重新加载(Context.Load()),
我在大约 15 分钟前刚刚完成了这项工作,因为 PCV 运气不好,所以我确信它可以做得更好,但希望这会让你继续前进。
Here's a workaround which I am using:
Instead of using the AddNew, on your DomainContext you can retrieve an EntitySet<T> by saying Context.EntityNamePlural (ie: Context.Users = EntitySet<User> )
You can add a new entity to that EntitySet by calling Add() and then Context.SubmitChanges() to send it to the DB. To reflect the changes on the client you will need to Reload (Context.Load())
I just made this work about 15mins ago after having no luck with the PCV so I am sure it could be made to work better, but hopefully this will get you moving forward.
对于我的特定情况,我认为最适合的是这样的(您的里程可能会有所不同):
使用 PagedCollectionView (PCV) 作为 context.EntityNamePlural (在我的例子中,context.ParentObjects)的包装器,它是一个 EntitySet。 (使用 loadOperation.Entities 对我不起作用,因为它始终是只读的。)
然后绑定到 PCV,但直接针对 context.EntityNamePlural EntitySet 执行添加/删除。 PCV 自动同步到对底层 EntitySet 所做的更改,因此这种方法意味着我不需要担心同步问题。
(直接对 EntitySet 执行添加/删除而不是使用 PCV 的原因是 PCV 的 IEditableCollectionView 实现与 EntitySet 不兼容,导致 IEditableCollectionView.CanAddNew 为“false”,即使底层 EntitySet 支持此功能。)
我认为 Kyle McClellan 的方法(请参阅他的答案)可能会受到某些人的青睐,因为它封装了对 EntitySet 的更改,但我发现就我的目的而言,没有必要在 loadOperation.Entities 周围添加 ObservableCollection 包装器。
非常感谢 Dallas Kinzel 一路以来提供的建议!
For my particular situation, I believe the best fit is this (Your Mileage May Vary):
Use a PagedCollectionView (PCV) as a wrapper around the context.EntityNamePlural (in my case, context.ParentObjects) which is an EntitySet. (Using loadOperation.Entities doesn't work for me because it is always read-only.)
Then bind to the PCV, but perform add/delete directly against the context.EntityNamePlural EntitySet. The PCV automatically syncs to the changes done to the underlying EntitySet so this approach means I don't need to worry about sync issues.
(The reason for performing add/delete directly against the EntitySet instead of using the PCV is that PCV's implementation of IEditableCollectionView is incompatible with EntitySet causing IEditableCollectionView.CanAddNew to be "false" even though the underlying EntitySet supports this function.)
I think Kyle McClellan's approach (see his answer) may be preferred by some because it encapsulates the changes to the EntitySet, but I found that for my purposes it was unneccessary to add the ObservableCollection wrapper around loadOperation.Entities.
Many thanks to to Dallas Kinzel for his tips along the way!