asp.net mvc分层应用程序，我理解正确吗？

Question

I've read a lot of asp.net mvc layered application I can find in the internet. Now, time to apply what I've learned. Please tell me if I'm doing it right or not. An example code would be great :D

This is just a simple layered application. Here goes,

<Company>.Data
        -- DataAccess (contains repo, interfaces and dbcontext)
        -- Mappings (mapping to models using fluent api)
        -- Migrations (schema migration)
        -- Filters (pipe and filter)
        - Product.cs
        - Customer.cs
        - Order.cs
<Company>.Service (consumes the interfaces and implementation)
        - ProductService.cs
        - CustomerService.cs
        - OrderService.cs
<Company>.Tests
<Company>.Web (ASP.NET MVC, have reference to Ninject, including ViewModels)

I'm wondering, in the <Company>.Service layer (if this should be the place where I should put my business logic) For example.

public class ProductService : IProductRepository
{
  public IQueryable<Product> GetProductByCustomer(int id)
  {
    // Some logic; Get all the products bought by the customer
  }
}

Then in my Controller

public class CustomerController : Controller
{
  private readonly ICustomerRepository _customerRepo;
  private readonly IProductRepository _productRepo;

  public CustomerControll(ICustomerRepository customerRepo,
           IProductRepository productRepo)
  {
    _customerRepo = customerRepo;
    _productRepo = productRepo;
  }

  public ActionResult Index(int id)
  {
    var customerProducts = _productRepo.GetProductByCustomer(id);
    return View(customerProducts.ToList());
  }
}

Please let me know if there is something I need to improve or some areas I need to add. I just want to start of simple then I'll climb my way through.

Note: I removed some code for brevity.

Really appreciated for your help. Thanks!

Answer 1

You can have a look at this repo

https://github.com/MarlabsInc/SocialGoal

It contains an example project implementing best practices using ASP.NET MVC, EF, service layer, repository pattern, unit of work pattern etc.

Answer 2

I'd change your ProductService so that it includes your repository using composition rather than inheritance . Or... as it looks very much like a repository anyway, maybe you meant to call it ProductRepository ? In which case you might still need a ProductService to hold your business logic.

EDIT

For example:

public class ProductService : IProductRepository
{
    public IQueryable<Product> GetProductByCustomer(int id)
    {
        // Some logic; Get all the products bought by the customer
    }
}

Would become:

public class ProductRepository : IProductRepository
{
    public IQueryable<Product> GetProductByCustomer(int customerId)
    {
        // Some logic; Get all the products bought by the customer
    }
}

And you would have some sort of business oriented function in your application/services layer:

public class ProductService
{
    private readonly IProductRepository productRepository;

    public ProductService(IProductRepository productRepository)
    {
        this.productRepository = productRepository;
    }

    public IEnumerable<Product> GetCurrentProductsOnOrderForCustomer(int customerId)
    {
        // etc.
    }
}

FURTHER EDIT

Usually in a layered architecture, you would only talk to the immediate layer below you (although architectures exist where you can talk to any layer below you, it may be the one you want). Your typical layered app would be laid out as UI/Presentation Layer -> Application/Service Layer -> Data Layer . Your Controllers would be in your UI Layer , usually with a reference to the Application/Service Layer , where things like your ProductService would live.

Answer 3

Why do you call you repository in you controller?? it's better to call repository interfaces in service and service interfaces in controller:

public class ProductService : IProductRepository
{
    private readonly IProductRepository _productRepository;

    public ProductService(IProductRepository productRepository) 
    {
        _productRepository=productRepository;
    }

    public IQueryable<Product> GetProductByCustomer(int id)
    {
        // Some logic; Get all the products bought by the customer
    }
}

and then in your controller:

public class CustomerController : Controller
{
  private readonly IProductService _productService ;

  public CustomerControll(IProductService productService)
  {
    _productService = productService;
  }

  public ActionResult Index(int id)
  {
    //call service here
  }
}

calling repository in controller is not a good practice if you have service layer and all business logic should be solved in domain layer not in service or other layers.

Answer 4

You're headed in the right direction, but I'll recommend some few changes. Since your <Company.Data> has folders for Mapping , Migration ... I think you should have a folder for your models Product, Customer, Order and call it Model , or you can place them in a different project and call it <Company.Model> .

I think you need to clearly define and understand what you mean by service. (a)It could be your applications main entry point, which other client (WebForms, MVC, or any presentation framework) interacts with. (b) You could refer to your service as your Domain service which defines the business rules/logic for your application.

If it's (b), this will interact with your repository(which handles retrieval of data from your data-store) and contains business rules. eg

ProductRepository : IProductRepository 
{
    public IEnumerable<Product> FindAll()
    {
        ....
    }
}


ProductService
{
    public void ProductService(IProductRepository productRepository)
    {
          _repository = productRepository;
    }

    //Business rules follows
}

If it's (a) this could be achieved in different ways based on your purpose and will communicate with your domain-service.