Design of an MVVM Application [closed]

Question

I am here very skeptical about the design of my application.....

Here is the Diagram for My application

is this right ?? ot i need to change something...

I'll Elaborate the Diagram.... :

Common Library : It Contains classes ErrorCodes,Utility Classes etc
Logger : Logging Framework
Exception Handling : Framework for handling exceptions

View: Contains : All the Different XAML for Views like UserControls,Windows,Popups

ViewModel : Contains ViewModels for the Differents Views.

Model : Contains holds the Different layers like ... Business Layer, Data Access layer etc

Entity layer : Contains the Entity Objects like Employee, Company etc...

File box : Its specify Reading/Writing from a file/ Database ....

Answer 1

Its hard to tell what you're trying to do with your question, but in my opinion MVVM layers should look like this:

• Model: Raw data and raw-data validation. Maybe an INotifyPropertyChanged as well, but nothing else

• ViewModel: Business Logic, data access, advanced validation based on business rules, etc

• Views: Pretty UI layer that allows users to interact with the ViewModels. Nothing else.

For example, a Model might have a File property, but it should not be responsible for showing the file dialog, saving the file to the database, or verifying that the file has a .pdf extension. That sort of stuff is the ViewModel's job.

Edit

I see the update you made to your question. It's an OK start, but here's the issues I have with it:

• Your models should be raw data objects. They should not contain anything more advanced than something like validating the length of a property.

• I honestly would not recommend separating the Views, Models, and ViewModels into 3 separate layers. I did that once and it turned out to be a maintenance nightmare. Now I put all related objects together. For example I'd put FileModel, FileViewModel, and FileView together, and SearchModel,SearchViewModel, and SearchView together

• I would create a Data Access Layer which would be responsible for doing all read/writing data to/from the database (I suppose this could be your "Entity Layer").

• For small projects, I tend to use my Entity Objects as my Models, so the Models become part of my DAL layer, although I know this is not recommended.

• Don't forget, with MVVM your ViewModels are your application, not your Views. The View should reflect what's in the ViewModel, and not vice versa.