Question

I am planning to create different layers, so in my Visual Studio Project, I will have:

BusinessLayer:
Contains Business objects (entities)
i.e User, Employee, Products etc

DataAccessLayer:
Entity Framework

Presentation Layers:
The Views & ViewModels

So say for example, I want to let user login to this application.

1. View will display the UI to let User to enter information.
2. When User press enter, execute command => ViewModel
3. ViewModel will use Entity Framework to query the User data from database, then ViewModel will initalize an User object (from BusinessObject ), and maps the User data to the User object.
4. This User object then will store into a static parameter for future use.

So what I really concern is:

1. Is this correct way to design N-layers?
2. Should I sperate each layers to different Visual Studio project?
   (i.e Business objects will be inside another project)
3. Is it better to let Business Object to query the data it self? So in
   Business Object construtor will calls entity framework?
4. Should I write a Repository class for use entity framework?

I don’t mind if this is complicated, because from what I have been told, this application will be huge. So I want to design it properly, to make it flexible and extendable.

Any advice will be great, thanks.

Answer 1

1 Is this correct way to design N-layers?

I would not say correct , but suitable for the project. Don’t see much problems in your design, by looking on question provided.

2 Should I sperate each layers to different Visual Studio project?
(i.e Business objects will be inside another project)

There is, basically, sence to do that when you’re going to reuse those layers in different projects/domains. Think about what you’re doing and what you’re possibly will do and decide if this is something you’re gonna do.

Consider that with the choice to make them a separate projects, architecture becomes more complicated, but also more scallable. Just an example, you can provide users with sperate patch of Business Layer fix, and do not install entire software packet. I repeat this is a choice. In most cases they just select to install all in once to avoid complexity (dependency management, versioning between different parts and all that mess…)

3 Is it better to let Business Object to query the data it self? So in
Business Object construtor will calls entity framework?

It’s better to have separated Query engine. More testable and scallable architecture.

4 Should I write a Repository class for use entity framework?

Again story about scallability. You can wrap EF, in this case you will have a possibility in one day, when you decide to relay on (say) SQLite+ORM, make change to it, without breaking all software infrastructure (as much as it possible naturally). But, consider, that implementing this you need much more time.

Balance your resources and time, and make a choices more appropriate to you and your project.