Rank 1
I'm developing in WPF trying to follow MVVM, and watching yor proyect sample wpfmvvmusingopenaccess, I have a little confusion. Open Access generated classes from tables automatically by model domain wizard into a EntityLibrary assembly. So far everything is ok, I created a ViewModel project to contain ViewModel classes to connect to xaml (xbap) (Presentation layer), but I note proyect sample have Business Objects classes into ViewModel assembly that reproduces in some way the same properties that Model classes (Model Assembly - table). ViewModel classes reference these Business Objects classes and same way Business Objects Classes reference Model classes.
1. ¿Business Objects classes are neccesary into model?, if so, it indicates I have to create business class for every related Model Class (table), OA can do this for me?
2. CRUD pages have to interchange data between components and ModelView properties, ¿must be the same properties as field tables (same properties as properties in model class)?
thanks for your help
3 Answers, 1 is accepted
Rank 1
I want to make clear something. OpenAccess Help in Quickstart shows how to integrate Classes populated from database (creating a Library) and ViewModel into WPF, making a class Model (derived from its Interface) for every class existing into before mentioned library, having only its CRUD operations (add, delete, save, etc) and then connecting this model class with its respective ViewModel class (with INotifyPropertyChange implementation) that has just few properties and interconnect with mentioned related model class, so I could understand XAML connects to ViewModel class and ViewModel class connects to its related Model Class and then Model Class connects to its related 'Entity' class to go to database.
Showing wpfmvvmusingopenaccess project of yours I note something. Model Library Project has Class constructed with respective attributes using Telerik.OpenAccess attributes that has to do with its related table and fields from database. ViewModelLibrary has Business Objects Class (with INotifyPropertyChanged implementation) for every class existing into before mentioned model library. Each one of business class has same properties as its related model class has (duplicated information), but add Delegate commands to implement CRUD operations (I understand this to implement relationship operations). And last, ViewModel class (derived from viewmodelbase implementing INotifyPropertyChanged), implement its own CRUD operations and has two operations, first one, goes into a repository that references directly to Model Class (populated from database's table) and execute operation, and next one, affecting Business Object Class respectively (ObservableCollection), I think duplicated operations.
In both samples there are some changes in the implementation.
1. I undestand n-tier implements presentation layer, business logic layer (that contains business classes) and data layer (that contains table related classes implementing sql operations) and entity layer (class per table).
2. I understand MVVM is closely related with XAML or WPF and to implement, it should have a ModelView class, Model class and Entity class (I guess)
Questions:
1. Which one of the samples is n-tier and which one is mvvm?
2. I need to make CRUD pages (xbap) that connect components with properties that are related with field of a table and make CRUD operations using OpenAccess classes populated from database. How can I achieve this, can you show me a sample?
3. Using MVVM in some way disagree with n-tier model?
4. Why second sample implements INotifyPropertyChanged in both of Business Class and ViewModel class?
5. Whichever case (MVVM - ModelView Class - or Business Objects Class) that connects directly to Presentation Layer, why is necesary to duplicate properties in these classes just as same properties into Entity classes which means we have to do the tediously task to create business class per entity class, but little different (logic and CRUD interop), and you can figure out that in MVVM model view must have same properties as model class as entity class to interconnect (three times duplicated properties, I guess)?
I appreciate so much your comments and help
The Business Objects in the MVVM example are an additional layer of abstraction that separates the concerns between the View, the ViewModel and the Model. A business object proves useful when you want to add some additional functionality or you want to encapsulate existing one. As in the MVVM example available in the OpenAccess SDK browser, the business objects implement the INotifyPropertyChanged interface and also define CRUD commands which can be bound to the view. Alternatively, the INotifyPropertyChanged interface implementation can be generated directly for the properties of the OpenAccess model persistent types as described in this help section. There is no universal recipe to follow here. Usually, introducing an additional layer with business objects is a more flexible approach resulting in loosely coupled and semantically coherent code. Depending on the concrete scenario you may find it more appropriate to use directly the model classes. So, if your CRUD pages use the OpenAccess model entities directly then you will need to use the properties generated by OpenAccess (with the INotifyPropertyChanged addition). If you choose business objects you will not need to change the code generation templates and you can leave your model in a state that is not concerned with ViewModel logic.
Let’s move to your other questions.
1.Both examples use the MVVM pattern – there is a ViewModel (for each view) which implements INotifyPropertyChanged and is used together with the binding system to separate the view from the business handling logic. A kind of an n-tier application could be considered the example with the business objects. The business objects layer is an additional one. We have WPF N-Tier examples which use data services or a plain WCF service and illustrate what is meant by several tiers. The plain WCF example uses data transport objects (DTO) which are automatically generated with our DTO templates. The examples are N-tier representatives where the services are isolated in a separate layer and the client application uses a repository to interact with the received data from the service. You can access the samples through the OpenAccess SDK browser.
2.Depending on what exactly you would like to bind to the view, the ViewModel can have different logic. As mentioned above, you may need to change the code generation templates if you want to directly bind the OpenAccess model entities to UI elements. Otherwise, you may use the example shown in the Getting Started Section of the online documentation as a reference and a guide.
3.Using MVVM does not contradict the use of several tiers. MVVM organizes the code in a predefined way so that the view is separated from the business handling logic which is in the ViewModel. The OpenAccess SDK browser WPF N-Tier examples are showing the integration between several tiers and MVVM.
4.The INotifyPropertyChanged is used to notify the view of changes to the ViewModel. It is necessary when the business objects properties are bound directly to some UI elements. In the second example the ObservableCollection takes care of changes to elements and INotifyPropertyChanged is not really necessary in the business object.
5.The business objects can be useful when you would like to bind separate properties of model entities to UI elements. For example, if you have a CategoryBO with a Description property that invokes OnPropertyChanged, a textbox can be directly bound to this Description property. The INotifypropertyChanged implementation is a must in this case. You can alternatively avoid this by having a selected category object in the ViewModel and a Description property on the ViewModel level that accesses the property of the category object. Using business objects is a matter of preference – it is a good practice to separate concerns and try to isolate some functionality in an additional object. When such functionality is not required the business objects can be skipped.
We do hope the provided information is helpful. Should you have more questions, feel free to contact us.
Petko_I
the Telerik team
Rank 1