使用 IDataErrorInfo 在 MVVM 中执行验证时,应该在哪里执行检查以查看数据库中是否已存在某个值?
开始使用所有这些 MVVM 的东西,我遵循这个 Josh Smith 的帖子讨论了使用 MVVM 时的验证方法。这个例子很简单,我开始想知道如何在我自己的应用程序中使用它。
我的 BLL 中有一个 BookInfo
类,它实现 IDataErrorInfo 来报告无效值,例如“发布日期不能是未来的”或“页数不能为负数”。然后我的 AddBookViewModel
将检查新创建的 BookInfo
的状态,查看是否存在错误,并且 AddBookView
将在适当的文本框。这些东西很简单,就像帖子中的示例一样。
现在我的 BookInfo
类还包含作者 ID 列表。在向我的数据库添加新的 BookInfo 时,我需要检查这些作者 ID 是否已存在。
是否应该在我的 BookInfo
类中完成此检查?如果是这样,那么我必须将 BLL 的 AuthorManager
对象传递给 BookInfo
的构造函数,因为前者将包含诸如 CheckIfExists(intauthorID) 之类的方法
。
这是推荐的方法吗?如果DB中有很多记录怎么办?动态检查会影响性能吗?
另一方面,在 BookInfo 类和其他地方执行一些检查似乎有点混乱......特别是当所有这些检查都可以归类到同一组时......即。确保新创建的 BookInfo
对象有效。或者也许我错了,因为我真的没有经验来做出正确的判断。
一些指导?
Getting started with all this MVVM stuff, I was following this post by Josh Smith that talks about an approach to validation while using MVVM. The example is simple, and I began to wonder how I would use it in my own application.
I have, in my BLL, a BookInfo
class that implements IDataErrorInfo to report invalid values such as "published date can't be in the future" or "number of pages can't be negative". Then my AddBookViewModel
would check the state of the newly created BookInfo
, see that errors exist, and the AddBookView
will display a red blob next to the appropriate TextBox. That stuff is straightforward, just like in the example in the post.
Now my BookInfo
class also holds a list of author IDs. On addition of a new BookInfo to my database, I need to check if those author IDs already exist.
Should this check be done in my BookInfo
class? If so, then I would have to pass in my BLL's AuthorManager
object to BookInfo
's constructor, since the former would contain methods such as CheckIfExists(int authorID)
.
Is this the recommended approach? What if there are a lot of records in the DB? Dynamically checking would affect performance?
On the other hand, it would seem a bit messy to perform some checks in the BookInfo
class and some elsewhere... especially when all those checks can be categorized into the same group... ie. making sure a newly created BookInfo
object is valid. Or maybe I'm wrong since I don't really have experience to make proper judgement.
Some guidance?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不会这样做。我会保持在“内部”
IDataErrorInfo
进行的验证简单且无上下文。任何依赖于上下文的验证(例如跨实体验证和依赖于数据库的验证)都会在您保存更改时执行该验证。在
IDataErrorInfo
中尝试这些更复杂的基于上下文的验证很容易出错,而且通常是不可能的。如果没有上下文,通常不可能可靠地做到这一点。我写了一篇关于此的博客文章。虽然它是在验证应用程序块的上下文中编写的(没有双关语),但它讨论了基于上下文的验证的一般问题。这可能会有帮助。 这里。
I wouldn't do this. I would keep the validations done 'inside'
IDataErrorInfo
simple and contextless. Any validations that depend on context, such as cross-entity validations and validations that are dependent on a database, do that validation when you save the changes.Trying these more complex context based validations in
IDataErrorInfo
will be error prone and often impossible. It is often impossible to do this reliably without a context.I've written a blog post about this. While it is written in the context (no pun intended) of the Validation Application Block, it talks about the general problem of context based validation. It might be helpful. Here it is.
我同意史蒂文的观点,即在尝试保存数据时应该执行服务器端验证。
造成这种情况的另一个原因是网络延迟。由于 WPF 对 IDataErrorInfo 的支持使用输入事件来确定何时验证属性,并导致对 VM 对象的阻塞/同步调用,因此 IDataErrorInfo 的使用对 UI 的响应能力有直接影响。您无法开始对数据库进行异步调用来执行验证,然后在网络调用完成时将验证错误分派到 UI 线程。您必须对数据库进行阻塞调用才能获取结果,这可能会在等待调用返回时对 UI 线程造成严重破坏。
我希望有一天 WPF 能够获得 Silverlight 精美的新 INotifyDataErrorInfo 接口,该接口允许我上面描述的异步验证场景。
I agree with Steven that you should perform the server-side validations when attempting to save the data.
Another reason for this is network latency. Since WPF's support for IDataErrorInfo uses input events to determine when properties are validated, and results in a blocking/synchronous call to your VM object, the use of IDataErrorInfo has a direct impact on the responsiveness of the UI. You cannot begin an async call to your database to perform the validation and then dispatch validation errors to the UI thread when your network call completes. You would have to make a blocking call to your DB to get the result, which could wreak havoc on the UI thread while it waits for the call to return.
I hope someday WPF gets Silverlight's fancy new INotifyDataErrorInfo interface, which allows for the async validation scenario I described above.