首先，我很欣赏在项目布局方面没有一个尺寸适合所有人，但是当我转向mvc时，我想尝试从坚实的基础开始。
目前，我正在努力使用asp.net mvc项目结构和n层和依赖注入（ninject）。我一直在阅读Pro Asp.net Mvc 3 Framwork，它将运动商店分成两个项目，这是一个不错的开始，但我想要更大的分离。
到目前为止，我认为我的项目应该类似于下面的大纲
Web UI（Asp.Net Mvc）
服务层
数据层
那么我的实体/模型在哪里？我相信我应该将它们移出Web UI，但我不完全确定它们适合的位置。
每个图层的单独实体是否会使用像automapper这样的东西在数据实体和服务实体之间进行映射，例如Microsoft的项目丝绸最初做的（这似乎是实现所需分离的相当大的开销）？或者是其他图层将引用的实体图层。该层将包含强类型数据集或可能位于基础结构标题下的Plain Old C Objects，然后可以在层之间传递，并通过视图模型在Web Ui层中自定义。
如果我正在使用Ninject，那么我应该在Composition Root（在这种情况下是Web Ui项目）中进行配置。
这意味着要添加对所有项目的引用，这些项目会破坏我尝试激活的分离。
答案 0 :(得分：2)
逻辑层！=物理层。结构越简单，项目越少，管理起来就越容易。
我通常有1个web项目，并使用名称空间作为我的逻辑层。通常我喜欢用于UI显示的视图模型和用于管理实体行为方式的域模型。
答案 1 :(得分：0)
那么我的实体/模型在哪里？
给他们自己的项目。
每个图层的单独实体是否会使用类似的内容 在数据实体和服务实体之间映射的automapper 微软的项目丝绸最初做了
尽量避免做多次映射。必须映射到视图模型是很自然的，但不是将实体的所有属性复制到视图模型中，而是将实体作为视图模型上的属性公开，并添加UI特定属性。如果所有UI需求都是该实体：请勿使用视图模型。这种额外的映射只会对应用程序的可维护性造成额外的负担。
还尝试防止必须从DA映射到您的实体。而是使用POCO实体作为实体框架，LINQ to SQL和NHibernate支持。同样，这个额外的映射可能不值得付出努力。
我在我的应用程序中使用的映射通常在另一个层面上。我围绕commands和queries设计我的业务逻辑，这甚至可以很好地转换为表示层。您可以使用MVC的绑定功能直接在视图上显示命令，将表单属性绑定回命令并执行它。通过一些额外的工作，MVC甚至可以让你完全支持编译时（即使在视图中）。