这是不好的做法吗（我做错了吗）？
在 silverlight LOB 应用程序中，我使用 RIA 服务 (EF) 请求的结果填充 ItemsControl。项目控件内部有一些自定义控件，其中一个控件有一个用于删除实体的按钮。
为了删除它，我将其附加到控件中的域上下文，然后将其删除。为了能够附加它，当我收到数据时，我在视图模型中执行此操作：
foreach(var app in Apps.ToList())
{
_context.Apps.Detach(app);
}
这是黑客吗？因为它确实感觉像一个。
In a silverlight LOB application I'm populating a ItemsControl with the results of a RIA services (EF) request. Inside the items control are some custom controls, and in one of them I have a button which I use to delete the entity.
To remove this I attach it to the domain context in the control and then remove it. To be able to attach it I am doing this in my view model when I receive the data:
foreach(var app in Apps.ToList())
{
_context.Apps.Detach(app);
}
Is this a hack? because it sure feels like one.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
模式的存在是为了服务开发人员，而不是相反。您已经识别出有臭味的代码。有件事让你烦恼。现在你必须做出两个选择。气味是否足以去除？以及您应该如何删除它。
一个建议。您不必将标准 CRUD 与 RIA 服务结合使用。您可以创建一个服务操作DeleteApp，它获取应用程序的ID并对数据库执行删除。这将避免在客户端执行分离等操作。这是 交易脚本 模式的示例，如我 我的文章中描述了，尽管这是一个非常基本的示例。执行此操作后，请不要忘记重新加载客户端列表，以免数据过时。
在最极端的情况下，您可能想要研究命令查询分离。在这种情况下，您有两个单独的 DomainServices，一个是只读的，另一个是只写的。这迫使您更加明确自己的行动，并更多地思考您想要做什么，而不是如何去做。
Patterns exist to serve the developer not the other way around. You've identified smelly code. Something that bothers you. Now there are two choices you have to make. Is the smell offensive enough to remove? And how should you go about removing it.
One suggestion. You don't have to use standard CRUD with RIA Services. You can create a Service Operation DeleteApp that takes the App's Id and perform the delete on the database. This would avoid the need to perform the detach and the like on the client side. This is an example of the Transaction Script pattern as I described in my article albeit a very rudimentary example. Don't forget to reload the client list after doing this so that you don't have stale data.
At the far extreme, you may want to look into command query separation. In this case you have two separate DomainServices one that is Read Only and the other that is Write only. This forces you to be more explicit with your actions and to think more about WHAT you want to do instead of HOW to do it.