using ProDinner as reference architecture

I have been looking at the Pro Dinner solution as a reference for a project I am working on and I think its largely suitable.. but I don't quite get the project structure.. from what I can see you would have three objects that would represent a single entity

Core – poco entities and interfaces for repositories and services
Data – data access layer, contains repositories implementations, EF5 Code First mappings and the DbContext
WebUI – all the ViewModels and the Mapper classes which are used to map from Entity to Input (ViewModel) and backwards, mvc controllers, views, images, scripts and some bootstrapping code

so from what I can see, say you had a Person Class.. you would have..

a Person entity in Core, a Person entity in Data and a PersonViewModel in WebUI..

is this correct? am I missing something?

would it be better to have Core contain just a single Person entity?

if anyone has another suggestion please let me know :)

thanks.

Solution

I’ve quickly downloaded ProDinner to have a look at the source code and its architecture.

I haven’t looked at everything in full details nor have I run the application.

From the looks of things, and to answer your question, my understanding is that you would only have to create a Person entity inside the Core.

You would not have to create a Person entity inside the Data layer BUT you would have to add a DbSet<Person> inside your DbContext (which happens to live inside the Data layer).

As for your ViewModel, it is important to understand that a ViewModel should be a representation of your UI.

For example, let’s assume your Person entity has 25 properties. Does it mean that your View will automatically show (or use) these 25 properties?

If the answer is yes, then you could simply strongly type your View directly to your Person entity OR create a PersonViewModel and copy the 25 properties from your Poco into that PersonViewModel. In turn, make your View strongly typed to this PersonViewModel.

On the other hand, if your View plans on only showing (or using) 10 properties out of the 25 properties, then create a PersonViewModel and only create those 10 properties.

As I said before, a ViewModel should be a representation of your UI (View) so knowing that your View will show/use 10 properties, it is pointless to have a PersonViewModel holding 25 properties.

Not every person or team likes to have a View strongly typed directly to a Poco but keep in mind that it would work. This choice is up to you (or your team).

Hope this helps clarify.