Excuse me, my team now put all view rules into the model's data validation? For example,we have a Wpf View which contains a radio button and a textbox which called "UserName" , now, there is rule that if you don't checked the raido button, you can't edit the textbox. So, the original model just has the username property, but after add rule, we must add a IsEditUserName property, and make the rules. Now, so far, so good . But, there is a question, the other team use the model. but they don't kown the IsEditUserName, so they can't very easy to use the model. It means they can't use like this model.username = "aa"; they should use make model.IsEditUserName = true frist.
So, I want to know what kind view rules can put into the model's data validation?
I look at it this way.
As you build your UI, if the rule would be required in a different UI (like in a web UI, or a service interface), then the rule belongs in the business object.
To put it another way, business objects are reusable. UI code is not. Any code written in a view or viewmodel is not reusable - it is tied to the specific UI you are building. Someday you'll discard that UI in favor of some new technology, and any code you wrote in the UI will need to be rewritten and retested in the new UI technology.
Any code you wrote in the business classes will probably work in the new UI technology with little or no change.
Another thing to consider is GIGO (garbage in, garbage out). Almost all validation is actually business logic, and therefore belongs in the business objects. Because the validation must happen for the rest of the app to function properly, it isn't a UI concept, it is a business concept.
Copyright (c) Marimer LLC