blocks|key|342471|text|我会说恰恰相反，我总是把我的INotifyPropertyChanged放在我的ViewModel上-你真的不想用像INotifyPropertyChanged这样的WPF特定功能来污染你的模型，那些东西应该放在ViewModel中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|342472|我相信其他人不会同意，但这就是我的工作方式。|342473|entityMap^0|E|M|1M|M|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

I'd say quite the opposite, I always put my <code>INotifyPropertyChanged</code> on my ViewModel - you really don't want to be polluting your model with a fairly WPF specific feature like <code>INotifyPropertyChanged</code>, that stuff should sit in the ViewModel.

I'm sure others would disagree, but that's the way I work.

blocks|key|344831|text|我会说在你的ViewModel里。它不是模型的一部分，因为模型是UI不可知的。模型应该是“除了业务不可知的一切”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|344832|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'd say in your ViewModel. It's not part of the Model as the Model is UI agnostic. The Model should be 'everything EXCEPT business agnostic'

blocks|key|343978|text|这取决于您是如何实现模型的。我的公司使用与Lhotka的CSLA对象类似的业务对象，并在整个业务模型中广泛使用INotifyPropertyChanged。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|343979|我们的验证引擎在很大程度上依赖于通过这种机制得到属性更改的通知，而且它工作得很好。显然，如果您正在使用不同于业务对象的实现，其中更改通知对操作不是那么关键，那么您可能有其他方法来检测业务模型中的更改。|343980|我们也有视图模型在需要的地方传播来自模型的更改，但是视图模型本身正在监听底层的模型更改。|343981|entityMap^0|1J|M|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

It depends on how you've implemented your model. My company uses business objects similar to Lhotka's CSLA objects and make extensive use of <code>INotifyPropertyChanged</code> throughout the business model.

Our validation engine relies heavily on being notified that properties change through this mechanism and it works very well. Obviously, if you are using a different implementation other than business objects where notification of changes isn't as critical to the operation, you may have other methods for detecting change in your business model.

We also have View Models that propagate the changes from the Model where needed, but the View Models themselves are listening to the underlying Model changes.

blocks|key|347487|text|在M-V-VM中，ViewModel始终(型号并非始终)实施INotifyPropertyChanged|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|347488|查看http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx提供的M-V-VM项目模板/工具包。它使用DelegateCommand进行命令，对于您的M-V-VM项目来说，它应该是一个很好的入门模板。|347489|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx^0|U|M|0|37|F|2|2K|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@$9|V|A|W|1|X]]|E|$]]|$1|H|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

In M-V-VM the ViewModel always (Model not always) implements <code>INotifyPropertyChanged</code>

Check out the M-V-VM Project Template/Toolkit from <a href="http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx" rel="nofollow noreferrer">http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx</a>.
It uses the <code>DelegateCommand</code> for commanding and it should be a great starting template for you M-V-VM projects.

blocks|key|343991|text|但有时(如在此演示link+text中)模型是服务，它为应用程序提供一些在线数据，然后您需要使用事件实现新数据到达或数据已更改的通知……|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|343992|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.lab49.com/archives/2650^0|9|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

But sometimes (as in this presentation <a href="http://blog.lab49.com/archives/2650" rel="nofollow noreferrer">link text</a>) model is service, which supplies application with some data online and then you need to emplement notification that new data arrived or data has changed using events...

blocks|key|343994|text|我强烈反对模型不应该实现INotifyPropertyChanged的观点。此界面不是特定于UI的！它只是简单地通知一个变化。事实上，WPF大量使用它来识别更改，但这并不意味着它是一个UI界面。我会把它比作下面的评论：“轮胎是汽车配件”。当然是，但是自行车、公交车等也用它。：总之，不要把那个界面当成是UI的东西。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|343995|话虽如此，但这并不一定意味着我认为Model应该提供通知。实际上，作为经验法则，模型不应该实现此接口，除非有必要。在大多数情况下，没有服务器数据被推送到客户端应用程序，模型可能会过时。但如果听取金融市场数据，那么我不明白为什么模型不能实现接口。例如，如果我有一个非UI逻辑，比如一个服务，当它收到给定值的出价或要价时，它会发出一个警报(例如，通过电子邮件)或下单？这可能是一个干净的解决方案。|BOLD|343996|然而，有不同的实现方式，但我总是主张简单，避免冗余。|343997|哪个更好？定义集合上的事件或视图模型上的属性更改并将其传播到模型，还是让视图本质上更新模型(通过视图模型)？|343998|无论何时你看到有人声称“你不能做这个或那个”，这是他们不知道自己在说什么的信号。|343999|这真的取决于你的情况，事实上MVVM是一个有很多问题的框架，我还没有看到通用的MVVM实现。|344000|我希望我有更多的时间来解释MVVM的多种风格和一些常见问题的解决方案--主要是由其他开发人员提供的，但我想我必须改天再做。|344001|entityMap^0|C|M|0|T|S|0|0|0|0|0|1A|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|H]]|D|@]|E|$]]|$1|I|3|J|5|6|7|10|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|11|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|12|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|13|8|@$9|14|A|15|B|H]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|16|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|T|$]]

I strongly disagree with the concept that the Model should not implement the <code>INotifyPropertyChanged</code>. This interface is not UI specific! It simply informs of a change. Indeed, WPF heavily uses this to identify changes, but that doesn't mean it is an UI interface.
I would compare it to the following comment: "A tire is a car accessory". Sure it is, but bikes, buses, etc. also use it. In summary, do not take that interface as an UI thing.

Having said that, it doesn't necessarily mean I believe that the Model should be providing notifications. In fact, as a rule of thumb, the model should not implement this interface, unless it is necessary. In most cases where no server data is pushed to the client app, the model can be stale. But if listening to financial market data, then I do not see why the model cannot implement the interface. As an example, what if I have non-UI logic such as a service that when it receives a Bid or Ask price for a given value it issues an alert (ex. through an email) or places an order? This could be a possible clean solution.

However, there are different ways of achieving things, but I would always argue in favor of simplicity and avoid redundancy.

What is better? Defining events on a collection or property changes on the view model and propagating it to the model or having the view intrinsically update the model (through the view model)? 

The bottom line whenever you see someone claiming that "you can't do this or that" it is a sign they do not know what they are talking about.

It really depends on your case and in fact MVVM is a framework with lots of issues and I am yet to see a common implementation of MVVM across the board.

I wish I had more time to explain the many flavors of MVVM and some solutions to common problems - mostly provided by other developers, but I guess I will have to do it another time.

blocks|key|3330678|text|我认为MVVM的名字很糟糕，将ViewModel称为ViewModel导致许多人错过了设计良好的体系结构的一个重要特性，即控制数据的DataController，无论谁试图触摸它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3330679|如果您认为视图模型更像是一个DataController，并且实现了DataController是唯一接触数据的项的体系结构，那么您将永远不会直接接触数据，而总是使用DataController。DataController对UI很有用，但不一定只对UI有用。它适用于业务层、UI层等。|3330680|DataModel+--------+DataController+------+View
++++++++++++++++++/
Business+--------/|code-block|syntax|javascript|3330681|你最终会得到一个这样的模型。即使是企业也应该只使用ViewModel接触数据。然后你的难题就消失了。|3330682|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I think MVVM is very poorly named and calling the ViewModel a ViewModel causes many to miss an important feature of a well-designed architecture, which is a DataController that controls the data no matter who is trying to touch it.

If you think of the View-Model as more of a DataController and implement an architecture where your DataController is the only item that touches the data, then you would never touch the data directly, but always use the DataController. The DataController is useful to the UI but not necessarily only for the UI. It is for business layer, UI layer, etc...

<pre><code>DataModel -------- DataController ------ View
 /
Business --------/
</code></pre>

You end up with a model like this. Even the business should only touch the data using the ViewModel. Then your conundrum just goes away.

blocks|key|3117911|text|通常，ViewModel将实现INotifyPropertyChanged。模型可以是任何东西(xml文件、数据库甚至对象)。Model用于将数据提供给视图模型，视图模型将传播到视图。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3117912|see+here|3117913|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/magazine/dd419663.aspx^0|F|M|0|0|8|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@]|D|@$9|T|A|U|1|V]]|E|$]]|$1|H|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

Normally ViewModel will implement the <code>INotifyPropertyChanged</code>. Model can be anything(xml file, database or even object). Model is used to give the data to the viewmodel, which propagates to the view.

<a href="http://msdn.microsoft.com/en-us/magazine/dd419663.aspx" rel="nofollow">see here</a>

blocks|key|3117923|text|假设视图中对象的引用发生了变化。为了显示正确的值，您将如何通知所有属性进行更新？在我看来，在视图中为所有对象的属性调用OnPropertyChanged都是垃圾。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3117924|因此，我所做的就是让对象本身在属性中的值发生变化时通知任何人，在我的视图中，我使用了Object.Property1、Object.Property2等绑定。这样，如果我只想更改视图中当前维护的对象，我只需执行OnPropertyChanged("Object")。|3117925|为了避免在加载对象的过程中收到成百上千的通知，我有一个私有的布尔指示器，在加载期间将其设置为true，它是从对象的OnPropertyChanged检查的，并且不执行任何操作。|3117926|entityMap^0|1N|H|0|16|G|1N|G|2X|R|0|1L|H|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|K|$]]

Suppose that the reference of the object in your view changes. How you will notify all properties to be updated in order to show the correct values? Calling <code>OnPropertyChanged</code> in your view for all object's properties is rubbish to my point of view.

So what I do is to let the object itself to notify anyone when a value in a property changes, and in my view I use bindings like <code>Object.Property1</code>, <code>Object.Property2</code> and on. In that way if I just want to change the object that is currently maintained in my view I just do <code>OnPropertyChanged("Object")</code>.

To avoid hundreds of notifications during the loading of objects, I have a private boolean indicator that I set it to true during loading which is checked from the object's <code>OnPropertyChanged</code> and does nothing.

blocks|key|3117965|text|我在一个模型中使用INotifyPropertyChange接口。实际上，模型属性更改应该仅由UI或外部客户端触发。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3117966|我注意到了几个优点和缺点：|3117967|优势|BOLD|3117968|通告程序在业务模型中|3117969|3117970|作为每个领域驱动，它是正确的。它应该决定何时筹集资金以及何时不筹集资金。|ordered-list-item|3117971|3117972|的劣势|3117973|该模型具有属性(数量、费率、佣金、总计)。Totalfrieght使用数量、费率、佣金变化计算。|3117974|3117975|从db加载值时，总费用计算被调用3次(数量，费率，佣金)。如果在业务层中分配了|3117976|，|3117977|，那么notifier+is+qty应该是一个禁用它的选项，可能是在基类中。但是，开发人员可能会忘记执行此操作。|3117978|3117979|entityMap^0|9|L|0|0|0|2|0|0|0|0|0|1|2|0|0|1C|0|0|0|13|0|0|1|0|0|1K|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|18|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|19|8|@$9|1A|A|1B|B|J]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1C|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]|$1|N|3|O|5|P|7|1E|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1G|8|@$9|1H|A|1I|B|J]]|D|@]|E|$]]|$1|T|3|U|5|6|7|1J|8|@$9|1K|A|1L|B|J]]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]|$1|W|3|X|5|P|7|1N|8|@$9|1O|A|1P|B|J]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1Q|8|@$9|1R|A|1S|B|J]]|D|@]|E|$]]|$1|10|3|11|5|P|7|1T|8|@$9|1U|A|1V|B|J]]|D|@]|E|$]]|$1|12|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]|$1|13|3|-4|5|6|7|1X|8|@]|D|@]|E|$]]]|14|$]]

I am using the <code>INotifyPropertyChange</code> interface in a model. Actually, a model property change should be fired by the UI or external client only.

I've noticed several advantages and disadvantages:

Advantages 

Notifier is in the business model

<ol>
<li>As per domain driven, it is right. It should decide when to raise and when not to.</li>
</ol>

Disadvantages

The model has properties (qty, rate, commission, totalfrieght). Totalfrieght is calculated using qty, rate, commission change.

<ol>
<li>On loading values from db, total frieght calculation is called 3 times (qty, rate, commission). It should be once.</li>
<li>If rate, qty is assigned in the business layer, again notifier is called.</li>
<li>There should be an option to disable this, possibly in the base class. However, developers could forgot to do this.</li>
</ol>

blocks|key|347647|text|我认为视图模型实现了INotifyPropertyChange，并且模型可以在不同的“级别”上使用通知。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|347648|例如，对于一些文档服务和document对象，您有一个documentChanged事件，视图模型将侦听该事件以清除和重新构建视图。在编辑视图模型中，您可以对文档的属性进行属性更改以支持视图。如果服务在保存时对文档做了很多事情(更新更改日期、最后一个用户等等)，那么你很容易得到Ipropertychanged事件的重载，只需一个documentchanged就足够了。|347649|但如果您在模型中使用INotifyPropertyChange，我认为最好在视图模型中传递它，而不是在视图中直接订阅它。在这种情况下，当模型中的事件发生变化时，您只需更改视图模型，而视图保持不变。|347650|entityMap^0|A|L|0|0|A|L|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

imho i think the viewmodel implements <code>INotifyPropertyChange</code> and the model could use notification on a different "level".

eg 
with some document service and a document object you have a documentChanged event that a viewmodel listens to to clear out and rebuild the view. 
In the edit viewmodel you have a propertychange for the properties of the document to support the views. If the service does a lot with the document on save (updating change date, last user and so on) you easy get a overload of Ipropertychanged events and just a documentchanged is enough. 

But if you use <code>INotifyPropertyChange</code> in your model i think it is good practice to relay it in your viewmodel in stead of subscribing to it directly in your view. In that case when the events change in your model you only have to change the viewmodel and the view stays untouched.

blocks|key|347663|text|只需在视图模型中使用INotifyPropertyChange，而不是在模型中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|347664|该模型通常使用IDataErrorInfo来处理验证错误，所以只要继续使用您的ViewModel，您就走上了MVVM之路。|347665|entityMap^0|A|L|0|7|E|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Just use the <code>INotifyPropertyChange</code> in your viewmodel and not in the Model,

the model usually uses the <code>IDataErrorInfo</code> to handle the validation errors so just keep in your ViewModel and you are right on your MVVM road.

blocks|key|342674|text|我认为这完全取决于用例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|342675|当你有一个具有大量属性的简单模型时，你可以让它实现INPC。简单地说，我的意思是这个模型看起来很像一个POCO。|offset|length|342676|如果您的模型更复杂，并且生活在交互式模型域中-模型引用模型，订阅其他模型的事件-将模型事件实现为INPC，这将是一场噩梦。|342677|把你自己放在某个模型实体的位置上，它必须与其他一些模型协同工作。您可以订阅各种活动。它们都被实现为INPC。想象一下您拥有的那些事件处理程序。一个巨大的if子句和/或switch子句的级联。|342678|INPC的另一个问题。你应该设计你的应用依赖于抽象，而不是实现。这通常是使用接口来完成的。|342679|让我们来看一下同一抽象的两种不同实现：|342680|public+class+ConnectionStateChangedEventArgs+:+EventArgs
{
++++public+bool+IsConnected+{get;set;}
}

interface+IConnectionManagerINPC+:+INotifyPropertyChanged
{
++++string+Name+{get;}
++++int+ConnectionsLimit+{get;}
++++/*

++++A+few+more+properties

++++*/
++++bool+IsConnected+{get;}
}

interface+IConnectionManager
{
++++string+Name+{get;}
++++int+ConnectionsLimit+{get;}
++++/*

++++A+few+more+properties

++++*/
++++event+EventHandler<ConnectionStateChangedEventArgs>+ConnectionStateChanged;
++++bool+IsConnected+{get;}
}|code-block|syntax|javascript|342681|现在看看他们两个。IConnectionManagerINPC跟你说了什么？它的一些属性可能会改变。你不知道他们中的哪一个。实际上，设计是只更改IsConnected，因为其余的都是只读的。|342682|相反，IConnectionManager的意图是明确的：“我可以告诉您，我的IsConnected属性的值可能会改变”。|342683|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Plain_Old_CLR_Object^0|0|1F|4|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1A|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1B|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1C|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1D|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

I think that it all depends on the use case.

When you have a simple model with loads of properties, you can have it implementing INPC. By simple I mean that this model looks rather like a <a href="http://en.wikipedia.org/wiki/Plain_Old_CLR_Object" rel="nofollow">POCO</a>.

If your model is more complex and lives in an interactive model domain - models referencing models, subscribing to other models' events - having model events implemented as INPC is a nightmare.

Put yourself in a position of some model entity that has to colaborate with some other models. You have various events to subscribe to. All of them are implemented as INPC. Imagine those event handlers you have. One enormous cascade of if-clauses and/or switch clausses.

Another issue with INPC. You should design your apps to rely on abstraction, not implementation. This is typically done using interfaces.

Let's have a look at 2 different implementations of the same abstraction:

<pre><code>public class ConnectionStateChangedEventArgs : EventArgs
{
 public bool IsConnected {get;set;}
}

interface IConnectionManagerINPC : INotifyPropertyChanged
{
 string Name {get;}
 int ConnectionsLimit {get;}
 /*

 A few more properties

 */
 bool IsConnected {get;}
}

interface IConnectionManager
{
 string Name {get;}
 int ConnectionsLimit {get;}
 /*

 A few more properties

 */
 event EventHandler&lt;ConnectionStateChangedEventArgs&gt; ConnectionStateChanged;
 bool IsConnected {get;}
}
</code></pre>

Now look at both of them. What does IConnectionManagerINPC tell you? That some of its properties may change. You don't know which of them. In fact the design is that only IsConnected changes, as the rest of them are read-only.

On the opposite, IConnectionManager's intentions are clear: "I can tell you that my IsConnected property's value may changed".

blocks|key|3330869|text|我认为如果您希望坚持使用MV-VM，那么答案是非常明确的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3330870|请参阅：http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx|offset|length|3330871|在MVVM模式中，视图封装UI和任何UI逻辑，视图模型封装表示逻辑和状态，模型封装业务逻辑和数据。|3330872|3330873|“视图通过数据绑定、命令和更改通知事件与视图模型交互。视图模型查询、观察和协调对模型的更新，并根据需要转换、验证和聚合数据以在视图中显示。"|blockquote|3330874|3330875|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx^0|0|4|1T|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@$D|W|E|X|1|Y]]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|11|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

I think the answer is quite clear if you wish to adhere to the MV-VM.

see:
<a href="http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx</a>

In the MVVM pattern, the view encapsulates the UI and any UI logic, the view model encapsulates presentation logic and state, and the model encapsulates business logic and data. 

<blockquote>
 "The view interacts with the view model through data binding,
 commands, and change notification events. The view model queries,
 observes, and coordinates updates to the model, converting,
 validating, and aggregating data as necessary for display in the view.
 "
</blockquote>

blocks|key|3118153|text|我同意保罗的回答，在模型中实现INotifyPropertyChanged是完全可以接受的，甚至是微软建议的-|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3118154|3118155|通常情况下，模型实现了可以轻松绑定到视图的工具。这通常意味着它支持通过INotifyPropertyChanged和INotifyCollectionChanged接口的属性和集合更改通知。表示对象集合的模型类通常派生自ObservableCollection<T>类，该类提供了INotifyCollectionChanged接口的实现。|blockquote|3118156|3118157|3118158|尽管这取决于你是否想要这种类型的实现，但请记住-|3118159|3118160|+如果您的模型类没有实现所需的接口怎么办？|BOLD|3118161|3118162|有时，您需要使用不实现INotifyPropertyChanged、INotifyCollectionChanged、IDataErrorInfo或INotifyDataErrorInfo接口的模型对象。在这些情况下，视图模型可能需要包装模型对象并向视图公开所需的属性。这些属性的值将由模型对象直接提供。视图模型将为它公开的属性实现所需的接口，以便视图可以轻松地将数据绑定到这些接口。|3118163|3118164|摘自-+http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx|3118165|我在一些项目中工作过，我们没有在我们的模型中实现INotifyPropertyChanged，因此我们面临着很多问题；VM中需要不必要的属性重复，同时我们必须在将它们传递到BL/DL之前更新底层对象(使用更新值)。|3118166|如果您需要处理模型对象的集合(例如，在可编辑的网格或列表中)或复杂模型，您将特别面临问题；模型对象不会自动更新，您必须在VM中管理所有这些对象。|3118167|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx^0|F|M|0|0|Z|M|1M|O|32|N|3W|O|0|0|0|0|0|1|K|0|0|B|M|Y|O|1N|E|22|K|0|0|4|1R|0|0|O|M|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|1D|8|@$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|1N|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1O|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|1P|8|@]|D|@]|E|$]]|$1|O|3|P|5|I|7|1Q|8|@$9|1R|A|1S|B|Q]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1U|8|@$9|1V|A|1W|B|C]|$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]|$9|21|A|22|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|23|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|24|8|@]|D|@$9|25|A|26|1|27]]|E|$]]|$1|X|3|Y|5|6|7|28|8|@$9|29|A|2A|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2B|8|@]|D|@]|E|$]]|$1|11|3|-4|5|6|7|2C|8|@]|D|@]|E|$]]]|12|$13|$5|14|15|16|E|$17|18]]]]

I agree with Paulo's answer, implementing <code>INotifyPropertyChanged</code> in Models is totally acceptable and is even suggested by Microsoft -

<blockquote>
 Typically, the model implements the facilities that make it easy to
 bind to the view. This usually means it supports property and
 collection changed notification through the <code>INotifyPropertyChanged</code> and
 <code>INotifyCollectionChanged</code> interfaces. Models classes that represent
 collections of objects typically derive from the
 <code>ObservableCollection&lt;T&gt;</code> class, which provides an implementation of the
 <code>INotifyCollectionChanged</code> interface.
</blockquote>

Although its up to you to decide whether you want that type of implementation or not, but remember -

<blockquote>
 What if your model classes do not implement the required interfaces? 
 
 Sometimes you will need to work with model objects that do not
 implement the <code>INotifyPropertyChanged</code>, <code>INotifyCollectionChanged</code>,
 <code>IDataErrorInfo</code>, or <code>INotifyDataErrorInfo</code> interfaces. In those cases,
 the view model may need to wrap the model objects and expose the
 required properties to the view. The values for these properties will
 be provided directly by the model objects. The view model will
 implement the required interfaces for the properties it exposes so
 that the view can easily data bind to them.
</blockquote>

Taken from - <a href="http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx</a>

I have worked in some projects where we haven't implemented <code>INotifyPropertyChanged</code> in our models and due to this we faced a lot of issues; unnecessary duplication of properties was needed in VM and at the same time we had to update the underlying object(with updated values) before passing them to BL/DL.

You will face problems specially if you need to work with collection of your model objects(say in an editable grid or list) or complex models; model objects won't be updated automatically and you will have to manage all that in your VM.

blocks|key|344197|text|绑定到我的视图的所有属性都在我的ViewModel中。因此，它们应该实现INotifyPropertyChanged接口。因此，视图将获得所有更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|344198|使用MVVM+Light工具包，我让它们继承自ViewModelBase。|344199|模型包含业务逻辑，但与视图无关。因此，不需要INotifyPropertyChanged接口。|344200|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

All properties, which are binded to my view, are in my ViewModel(s). Thus they should implement the INotifyPropertyChanged interface. Therefore the View gets all changes. 

[Using the MVVM Light toolkit, I let them inherite from ViewModelBase.]

The Model holds the business logic, but has nothing to do with the view. Thus there´s no need for the INotifyPropertyChanged interface.

blocks|key|345132|text|如果模型在ViewModel中明确公开，则可以在模型中实现INPC。但通常情况下，ViewModel包装模型是他自己的类，以降低模型的复杂性(这对于绑定来说不应该是空的)。在这种情况下，INPC应该在ViewModel中实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|345133|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Implementing INPC in models could be used if the models are plainly exposed in the ViewModel. But generally, the ViewModel wrap the models is his own classes to reduce the model complexity (which should not be usefull for the binding). In this case the INPC should be implemented in the ViewModel.

Most MVVM examples I have worked through have had the Model implement <code>INotifyPropertyChanged</code>, but in <a href="http://www.codeproject.com/KB/WPF/VMCommanding.aspx" rel="noreferrer">Josh Smith's CommandSink example</a> the ViewModel implements <code>INotifyPropertyChanged</code>.

I'm still cognitively putting together the MVVM concepts, so I don't know if:

<ul>
<li>You have to put the <code>INotifyPropertyChanged</code> in the ViewModel to get <code>CommandSink</code> to work</li>
<li>This is just an aberration of the norm and it doesn't really matter</li>
<li>You should always have the Model implement <code>INotifyPropertyChanged</code> and this is just a mistake which would be corrected if this were developed from a code example to an application</li>
</ul>

What have been others' experiences on MVVM projects you have worked on?

In MVVM should the ViewModel or Model implement INotifyPropertyChanged?

文档服务

数据库

服务器

我使用过的大多数INotifyPropertyChanged.示例都让模型实现了INotifyPropertyChanged，但在 中，ViewModel实现了 MVVM我还在整理MVVM的概念，所以我不知道是否：您必须将INotifyPropertyChanged放在ViewModel中才能使CommandSink工...

问在MVVM中，ViewModel或模型应该实现INotifyPropertyChanged吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在MVVM中，ViewModel或模型应该实现INotifyPropertyChanged吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在MVVM中，ViewModel或模型应该实现INotifyPropertyChanged吗？
EN