我读过很多asp.net的MVC分层应用，我可以在互联网上找到。 现在，时间运用我学到的东西。 请告诉我，如果我这样做是正确与否。 一个例子的代码将是巨大的：d
这只是一个简单的分层应用。 开始，
<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)
我想知道，在<Company>.Service层（这应该是我应该把我的业务逻辑的地方）。例如。
public class ProductService : IProductRepository
{
public IQueryable<Product> GetProductByCustomer(int id)
{
// Some logic; Get all the products bought by the customer
}
}
然后在我的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());
}
}
请让我知道如果有什么我需要改进或某些领域，我需要补充。 我只是想开始的简单的话，我会通过爬上我的路。
注：我删除了简洁一些代码。
非常感谢您的帮助。 谢谢！
我会改变你的ProductService ，使其使用组合而不是继承包括你的资料库。 还是......因为它看起来非常像一个仓库，无论如何，也许你的意思是把它ProductRepository ？ 在这种情况下，你仍然可能需要一个ProductService握住你的业务逻辑。
编辑
例如：
public class ProductService : IProductRepository
{
public IQueryable<Product> GetProductByCustomer(int id)
{
// Some logic; Get all the products bought by the customer
}
}
会成为：
public class ProductRepository : IProductRepository
{
public IQueryable<Product> GetProductByCustomer(int customerId)
{
// Some logic; Get all the products bought by the customer
}
}
而你也有某种在你的应用程序/服务层业务为主的功能：
public class ProductService
{
private readonly IProductRepository productRepository;
public ProductService(IProductRepository productRepository)
{
this.productRepository = productRepository;
}
public IEnumerable<Product> GetCurrentProductsOnOrderForCustomer(int customerId)
{
// etc.
}
}
进一步编辑
通常在一个分层架构，你只会跟下面你眼前层（虽然存在的架构，你可以跟下面你的任何一层，它可能是你想要的）。 典型的多层应用程序将被布置为UI/Presentation Layer - > Application/Service Layer - > Data Layer 。 你的Controllers会在你的UI Layer ，通常与该参考Application/Service Layer ，那里的东西像你ProductService会住。
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.
你为什么叫你在你控制器存储库？ 最好是调用服务和服务接口库接口控制器中：
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
}
}
然后在你的控制器：
public class CustomerController : Controller
{
private readonly IProductService _productService ;
public CustomerControll(IProductService productService)
{
_productService = productService;
}
public ActionResult Index(int id)
{
//call service here
}
}
在控制器调用库是不是如果你有业务层和所有的业务逻辑应该在领域层来解决不在服务区或其他层一个很好的做法。
你朝着正确的方向，但我会推荐一些一些变化。 由于您的<Company.Data>对文件夹Mapping ， Migration ......我想你应该有一个文件夹，你的模型Product, Customer, Order和叫它Model ，或者您也可以将它们放置在不同的项目，并调用它<Company.Model>
我认为你需要明确界定和理解你的服务是什么意思。 （一）这可能是您的应用程序主入口点，这是其他客户端（Web窗体，MVC，或任何表现的框架）与交互。 （b）你可以访问你的服务的定义为您的应用程序的业务规则/逻辑您的域名服务。
如果是（B），这将与您的存储库（即处理数据的检索您的数据存储），包含业务规则进行交互。 例如
ProductRepository : IProductRepository
{
public IEnumerable<Product> FindAll()
{
....
}
}
ProductService
{
public void ProductService(IProductRepository productRepository)
{
_repository = productRepository;
}
//Business rules follows
}
如果它是（a）本会根据您的目的，不同的方式来实现，将与您的域名服务进行通信。
