ASP.NET MVC（域模型、存储库、Fluent、服务 - 我的项目的结构）
在我的 ASP.NET MVC Web 应用程序中，我有：
由 LINQ to SQL 创建的域模型
存储库，例如
UserRepository和OrderRepositoryIQueryable Fluents IQueryable 扩展方法如
public IQueryable<订单>; GetNewOrders(this IQueryable) 服务如
UserService和OrderService实用程序类和扩展方法如
CryptoUtility（进行哈希等）和字符串等扩展每个 MVC 视图专用的 ViewModel
ASP.NET MVC 项目本身（控制器、视图）
我正在寻找适合我的案例的最佳项目结构/组织，特别是分成不同的程序集以及这些层之间的依赖关系应该是什么样子。不幸的是，网络资源没有详细介绍这一点。
一个提示：当前存储库、服务、IQueryable Fluents 等直接针对域模型实现工作，我没有它们的接口定义。我认为这是不必要的，但也许这是松耦合所需要的？我的服务有一个接口（例如 IOrderService），并且我的存储库实现 IRepository
感谢您以简洁的方式组织这一点的意见，特别是哪一层应该依赖于什么？装配组织。谢谢你！
In my ASP.NET MVC web application, I have:
Domain Model, created by LINQ to SQL
Repositories such as
UserRepositoryandOrderRepositoryIQueryable Fluents as IQueryable Extension Methods such as
public IQueryable<Order> GetNewOrders(this IQueryable<Order>)Services such as
UserServiceandOrderServiceUtility Classes and Extension Methods such as
CryptoUtility(doing Hashing etc.) and String etc. extensionsViewModels which are special for each MVC View
The ASP.NET MVC project itself (Controllers, Views)
I'm looking for the best project structure/organization for my case, especially separating into different assemblies and how dependencies should look like between these layers. Web resources unfortunately don't go into good detail about this.
One hint: Currently Repository, Services, IQueryable Fluents etc. work directly against domain model implementation, I don't have an interface definition for them. I considered it unnecessary but maybe this is needed for loose coupling? My Services have an interface (e.g. IOrderService), and my repositories implement IRepository<T>.
Appreciate your input on organizing this in a concise manner, and especially what layer should depend on what & assembly organization. Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会在此处查看 Jeffrey Palermo 关于洋葱架构的文章。这种基本架构适用于任何项目，并且允许您将核心项目（域层、持久性等）与 Web 项目分开。
我们将其与 MVC/StructureMap/FluentNHibernate 一起使用，并取得了巨大的成功。
我们最终得到了类似于下面的结构。
这就是基本的想法。 Web 应用程序引用了我们的存储库/工作单元的域实体的核心应用程序。查看 Google 上的这个旧项目类似示例的代码。最重要的是，我们能够将新的“UI”项目类型添加到同一解决方案中，并按预期重新使用我们的核心项目。比如控制台应用程序或第二个网络应用程序，或任何您需要的东西。
I would look at the article by Jeffrey Palermo on the Onion Architecture here. This basic architecture works well in any project and will allow you to separate your core project (domain layer, persistence, etc.) from your web project.
We use this with MVC/StructureMap/FluentNHibernate and have had great success.
We end up having a structure similar to the one below.
That's the basic idea. The web app references the core app for domain entities our repository/unit of work. Check out this older project on google code for a similar example. The great part about this is we have been able to add new "UI" project types to the same solution and re-use our core project as intended. Like a console app or a second web app, or whatever you need.
几个不同的项目确实对此进行了更详细的介绍（但请注意，还需要付出一些努力才能真正理解所有不同部分如何协同工作）
A couple of different projects do go in more detail about this (but mind you it also takes some effort to really understand how all the different parts work together)
您可能需要查看 s#arp 架构，了解它们的结构。它使用 NHibernate 并且它们的存储库与它们直接相关，因此您需要对其进行修改。
You might want to check out s#arp architecture to see how they structure things. It uses NHibernate and their repos are kinda directly tied to them so you'll need to modify it.