1

首先，我很欣赏在项目布局方面没有一刀切的，但是当我转向 mvc 时，我想尝试从坚实的基础开始。

目前，到目前为止，我在 asp.net mvc 项目结构和 n 层和依赖注入（ninject）方面真的很挣扎。我一直在阅读 Pro Asp.net Mvc 3 Framwork，它将体育商店分为两个项目，这是一个不错的开始，但我想要更大的分离。

到目前为止，我认为我的项目应该类似于下面的大纲

  • 网页界面 (Asp.Net Mvc)

  • 服务层

    • 服务接口（摘要）
    • Service（服务接口的具体实现）

  • 数据层

    • 数据接口（摘要）
    • 数据（服务接口的具体实现）

那么我的实体/模型在哪里？我相信我应该将它们移出 Web UI，但我不完全确定它们适合哪里。

是否会为每一层使用单独的实体并使用类似 automapper 的东西在数据实体和服务实体之间进行映射，就像 Microsoft 的项目 Silk 最初所做的那样（这似乎是实现所需分离的相当大的开销）？或者其他层将引用的实体层。该层将包含强类型数据集或可能在基础设施标题下的普通旧 C 对象，然后可以在层之间传递并通过视图模型在 Web Ui 层中进行自定义。

此外，如果使用 Ninject，那么我应该在 Composition Root（在这种情况下为 Web Ui 项目）中配置它。

这意味着添加对所有项目的引用，这会破坏我试图激活的分离。

4

2 回答 2

2

逻辑层！=物理层。结构越简单，项目越少，管理起来就越容易。

我通常有 1 个 Web 项目并使用命名空间作为我的逻辑层。通常我喜欢有用于 UI 显示的视图模型和域模型来管理实体的行为方式。

于 2012-10-24T14:00:18.893 回答
0

那么我的实体/模型在哪里？

给他们自己的项目。

是否会为每一层使用单独的实体，并使用诸如自动映射器之类的东西在数据实体和服务实体之间进行映射，就像 Microsoft 的项目 Silk 最初所做的那样

尽量避免做太多的映射。必须映射到视图模型是很自然的，但不要将实体的所有属性复制到视图模型中，只需将实体作为属性公开在视图模型上并添加特定于 UI 的属性。如果 UI 需要的只是那个实体：不要使用视图模型。这种额外的映射只会给应用程序的可维护性带来额外的负担。

还要尽量避免必须从 DA 映射到您的实体。而是使用 POCO 实体作为实体框架、LINQ to SQL 和 NHibernate 支持。同样，这种额外的映射可能不值得付出努力。

我在我的应用程序中使用的映射通常在另一个层次上。我围绕命令和查询设计我的业务逻辑，这甚至可以很好地转化为表示层。您可以使用 MVC 的绑定功能直接在视图上显示命令，将表单属性绑定回命令并执行它。通过一些额外的工作，MVC 甚至可以让您完全支持编译时（即使在视图中）。

于 2012-10-24T14:08:52.917 回答