Where do models belong in my solution?

StackOverflow https://stackoverflow.com/questions/20590121

Question

This is the first time I'm doing a web project using MVC and I'm trying to make it based on three layers : MVC, DAL (Data Access Layer) and BLL (Business Logic Layer).

I'm also trying to use repositories and I'm doing it code-first.

Anyway I've searched a lot on the web but yet if you've got a good reference for me I'll be glad to see it .

My current project looks like this:

current project

And here are my questions:

  1. Where are the Product and User classes that represent tables supposed to be? It seems that I need to use them in the BLL and I don't really need them in the DAL but for the PASContext.

  2. Where do I initiate the PASContext? In all of the examples I've seen on the internet no one made a constructor in the repository that takes 0 argument, which means that the context is not created within the repository (and I've read some reasons why like so all repositories will use one context).

If I'm trying to initiate the PASContext in the ProductBLL the compiler says it doesn't recognize it and I'm missing a reference (although I've added the needed reference and the name PASContext is marked in a blue like vs did recognize it)

PASContext is the class that is inherited from DbContext.

Here is some code to demonstrate:

public class ProductsBLL
{
    private EFRepository<Product> productsRepository;
    private List<Product> products;

    public ProductsBLL()
    {
        PASContext context = new PASContext();
        productsRepository = new EFRepository<Product>(context);         
        //LoadData();
    }
  1. About the View models, if I want, for example, to present a list of products for the client, do I need to create a ProductViewModel, get the data from ProductsBLL which has a list of Product and convert it to a list of ProductViewModel and then send it to the controller?

In addition, in the ProductController, do I only initiate ProductsBLL? I don't initiate any repository or context, right?

If someone could show me some project that uses repository, three-tier architecture and takes data from the database, transfers it to the BLL and from there to the MVC layer and using a ViewModel show it to the client it will be great.

Was it helpful?

Solution

Question 1

Where are the Product and User classes that represent tables supposed to be?

I would have these in a project that can be referenced by all other projects. That is, all other projects can depend on the solution with the models. In the case of onion architecture the models belong in the core which is at the center of the solution.

Onion architecture overview

In your case I'd put them in the BLL.

Question 2

Where do I initiate the PASContext?

The reason why you don't normally see this done directly is because it's very common to use Dependency Injection or DI (What is dependency injection?)

This means that you don't need to instantiate a DbContext directly; you let the DI container do it for you. In my MVC applications the context has a PerWebRequest lifestyle.

PerWebRequest Lifestyle:

Instance of a component will be shared in scope of a single web request. The instance will be created the first time it's requested in scope of the web request.

A context is created when the request is made, used throughout the request (so all repositories gain the benefits of the first-level caching) and then the context is disposed of when the request is completed. All of it is managed by the DI container.

Question 3

do I need to create a ProductViewModel [...] ?

You generally only have one view-model to give to a view. The view should be its own object that has all of the things that the view needs in order to display everything. You suggest that you create multiple view-model objects and pass that to the view. My concern with that approach is what happens if you want to display more information for that view? Say, you want to display a single DateTime object to the user. Now you want to display one of something but you're passing many objects to the view.

Instead, separate things up. Create a single view-model and pass that to the view. If you have a part of the view that needs to display many of something, have the view call it as a child action or partial so that the view isn't doing too much.

Your approach:

Approach #1

A different approach:

Approach #2

Conclusion

If someone could show me some project that uses [...] three-tier architecture

I'm not sure about three-tier architecture. Here are some example projects that use a variety of solution architectures:

There is no single correct approach - just good and bad approaches.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top