Menu
If I am generating POCO objects from EntityFramework, and using these to go to/from the WCF server, is there any reason to create client-side Models for the Views & ViewModels to use instead of just using the POCOs directly?
Almost all the MVVM examples I have looked at bind straight to the object returned from the WCF service. Is this good practice? Are there arguments that can be made for actually mapping the POCO to a Model and having the Views/ViewModels working with the Model object instead of the POCO?
The main reason I could think of is validation, however since the EF POCOs are partial classes, they can be expanded on to include validation.
EDIT
Most answers so far have brought up INotifyPropertyChanged as the main reason to build a separate Model. Does your answer change if you are using Self-Tracking entities instead of POCOs which already includes INotifyPropertyChanged? STEs are also partial classes which can be expanded upon to include validation.
423
A POCO is your Business Object. It has data, validation, and any other business logic that you want to put in there. But there's one thing a POCO does not have, and that's what makes it a POCO. POCOs do not have persistence methods.
These classes (POCO classes) implements only the domain business logic of the Application. Some developers use Data Transfer Objects (DTOs) with the classes to pass the data between the layers because POCOs are also used to pass the data between the layers, but they become heavy.
In software engineering, a plain old CLR object, or plain old class object (POCO) is a simple object created in the . NET Common Language Runtime (CLR) that is unencumbered by inheritance or attributes.
POCO Data is POCO's database abstraction layer which allows users to easily send/retrieve data to/from various databases. Currently supported database connectors are SQLite, MySQL/MariaDB, PostgreSQL and ODBC (which covers SQL Server and other databases).
Validation is the main reason not to bind directly to a POCO. In addition, if the POCO doesn't already implement INotifyPropertyChanged and other required interfaces, the experience working with the object on the WPF side may be less desirable, and implementing a ViewModel to wrap this makes sense.
Providing a ViewModel to wrap your POCO allows you to encapsulate the logic into ICommand implementations as well as implement required interfaces cleanly.
122
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
