ASP.NET MVC的解决方案最佳结构 [英] Best Structure for ASP.NET MVC Solution

问题描述

我试图构建遵循最佳实践方法我的最后一个相当大的MVC项目，但并没有很明白我在做什么。

I tried to structure my last sizeable MVC project following a best practice approach, but didn't quite understand what I was doing.

它有一个数据，业务和网络（MVC）项目，但控制器包含大部分code，数据层使用NHibernate和有负责的事情太多了几个仓库和业务层是对于任何不中的其他两个项目都属于倾销地。它的工作原理，但我觉得它可能是更好的设置 - 我不满的主要事情是脂肪控制器和存储库

It has a Data, Business and Web (MVC) project, but the controllers contain most of the code, the Data layer uses NHibernate and has a few repositories responsible for too many things, and the Business layer is a dumping ground for anything that doesn't belong in the other two projects. It works, but I feel it could have been setup better - the main things I'm unhappy with are the fat controllers and the repositories.

我开始，可能成长为一个体面的大小一个新的项目，所以我花了更多的时间试图让我的设计都一目了然。看了多一点，我想有每个聚集根的存储库，然后在在presentation层每个控制器业务层的服务。

I'm starting a new project that might grow to be a decent size, so I'm spending a bit more time trying to get my design right up front. Having read a bit more, I'm trying to have a repository per aggregate-root, and then have a service in the Business layer for each controller in the presentation layer.

我最初的希望是，该code的大部分会去服务，这再加上更小的存储库将保留我的控制器和数据层较薄。到目前为止，虽然，这是不会发生。

My initial hopes were that the bulk of the code would go in the services and this coupled with the smaller repositories would keep my controllers and data layer thin. So far though, this isn't happening.

我读过的一切表明，视图模型不应该从业务层被退回，并应在presentation层进行填充，所以此刻我的服务层主要通过模型从我的数据层通过到presentation层，然后做什么它需要prepare的视图模型。所以，我仍然有脂肪控制器，再加上超薄的业务和数据层。

Everything I've read suggests that the View Models should not be returned from the Business layer, and should be populated in the presentation layer, so at the moment my service layer is mainly passing models from my data layer through to the presentation layer which then does what it needs to prepare the view models. So I still have fat controllers, plus a thin business and data layer.

我的presentation层也知道我的两个业务和数据层，但我认为这种分离点的部分是降低耦合？

My presentation layer also knows about both my business and data layer, but I thought part of the point of this separation was to reduce coupling?

有我得到这一切错了吗？我是否应该停止尝试盲目跟随我在互联网上阅读，只是prepare视图模型在业务层，所以我可以在那里移动散装我的code的？我是不是应该回到传统的ASP？ ：）

Have I got this all wrong? Should I stop trying to blindly follow what I read on the internet and simply prepare view models in the business layer so I can move the bulk of my code in there? Should I just go back to classic ASP? :)

推荐答案

这是我使用当我建立一个项目的结构，以确保我可以添加一些OperationContract的属性，业务逻辑层，然后主机主引导它作为一个WCF服务。

the main guide that I use when I am setting up a project structure is to ensure that I can add some operationcontract attributes to the business logic layer, and then host it as a wcf service.

如果我能做到这一点，就意味着业务逻辑层分离出了我的数据层，只有通过结构简单和实体与客户端进行交互。数据层是完全隐藏。

If i can do this, that means the business logic layer has isolated my data layer, and is interacting with its client only by passing simple structures and entities. the datalayer is completely hidden.

所以我平时的结构是这样的：

So my usual structure looks like:

Solution
    Business.Contracts (interfaces for bll layer in here)
    Business.Logic     (concrete implementations of contracts in here)
    Business.Entities  (Pocos that bll uses)
    Data.Contracts     (interfaces for dal)
    Data.Sql           (Concrete Sql implementation of contracts)
    Common.Enums       (Enums needed by all projects)
    FrontEnd           (Main mvc app)

因此​​，在这种结构中，我的MVC项目永远只与业务空间和公共空间的交易。

So in this structure, my mvc project only ever deals with the business namespace and the common namespace.

然而，当与实体的互动，我倾向于使用我自己的模型在MVC项目让我添加注释和前端特定的功能，那么我提供这些模型隐式转换为能够被用交替使用经营实体。

When interacting with the entities however, I tend to use my own models in the mvc project to allow me to add annotations and front end specific functionality, then i provide implicit conversions for these models to be able to be used interchangeably with the business entities.

心连心

这篇关于ASP.NET MVC的解决方案最佳结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！