I am writing my first WPF application. I have also installed Entity Framework (EF) 4.1. I am a newbie in both. I am also learning to write MVVM classes by referring to a sample code.
I want to know whether I should first design classes for the Model, View and ViewModel or first design the database schema and use EF to auto-generate classes. Which is the recommended approach?
I have created three folders in my Visual Studio solution namely: Model, View and ViewModel. I will be adding respective classes to these folders. Any suggestions on this as well?
The main feature in Entity Framework 4.1 is Code-First development style and I would recommend to use this feature when you start with a new application and don’t have an existing database schema you have to start with.
This means that you design your model classes first, specify perhaps some mapping details with either data annotations or in Fluent API and let EF generate database and database schema. In many cases you don’t need data annotations or Fluent API at all because EF 4.1 follows a set of mapping conventions, which means that EF can infer the necessary database schema from naming conventions of your classes and properties. This makes mapping of model to database very easy in many situations.
In both approaches – database first or code first – you have to keep in mind that you want a working mapping between the two worlds. You can create model classes which can not or not easily mapped to a relational database schema and on the other side you can create a database schema which is difficult or impossible to map to model classes. So it makes sense to get familiar with examples how to create model classes which can be mapped to a database with EF 4.1.
It’s somewhat a matter of taste if you want to start with the database schema or the model (and perhaps depends on if you have mighty database administrators behind your neck who possibly don’t like autogenerated database schemas). But in my opinion Code-First speeds up your development.
Edit
To your question about project organization: Having Views and ViewModels in one (“WPF-UI”) project is fine because they belong close together anyway. It’s also not wrong to put the model and all the EF stuff in this project. But there are good arguments to move Model and EF into a separate project (class library) in your solution. It allows you more easily to have other applications which access model and database (for instance simple tool programs (console app) to test something or do some work on the database).
Many people would vote also to separate model and EF into separate projects (a “Domain or Business Logic project” and a “EF persistance layer project” or something). But since you say you are starting, this is perhaps too much of layered abstractions which can quickly get out of hand. You can always refactor at a later stage if you want a stronger separation of concerns.