需要对ASP.NET MVC 3体系结构的一些指导

Question

我是一个经验丰富的.NET开发人员，主要从事webforms的工作。我熟悉MVC，但还没有在商业上使用它。我目前正在这方面进行一些自我教育，对建筑问题的不同意见有些困惑，让我在这个问题的前面加上一个理解，即没有正确或错误的答案，但我只是在寻求一个优雅的解决方案。

我首先要说的是，我不使用实体框架或任何类型的ORM --我想直接实现我自己的业务对象和数据访问代码(使用ADO、SPROCS等)以确保它们是最佳的，这是个人偏好。在这里，我很难找到一致的信息，因为似乎大多数信息都与LINQ或实体框架的使用有关。

我的应用程序由以下项目组成：

• Web (MVC 3 Web应用程序)
• 模型(类库)

只有两个项目，因为我有问题解耦；这是我的问题的根源。我的模型类库包含…

• 具有字段和属性的经典业务对象
• 每个业务对象的存储库类，其中包含数据访问代码(ADO.NET、直接向前、SqlDataReaders等)
• 每个存储库类的接口

我的问题是所有这些层之间的依赖关系。感觉一点都不对劲！

1.业务对象应该包含实现业务逻辑的方法，所以除了字段和属性之外，还有实现任何所需逻辑的方法？

2.存储库类执行数据访问代码，但了解业务对象，这同样感觉不对，数据访问代码应该放在自己的类库中，而对对象一无所知吗？

3.控制器(在web层中)利用存储库接口，但为什么？它们不应该包含业务逻辑，“模型”还是业务对象应该包含？控制器当然不应该包含业务逻辑，所以这也是不对的。我不想在存储库中使用业务逻辑，因为它们正在访问数据库。

我很难为应用程序找到一个优雅的体系结构，只是一个如何实现我自己的对象、我自己的数据访问代码和确保应用程序松散耦合的基本大纲。有人能给我指点吗？

Answer 1

我建议对您的解决方案结构进行一些更改。

例如，这些项目的结构如下：

核心图书馆

这将是一个简单的POCO，它代表您的域数据和任何服务的接口。这里没有业务逻辑。只是简单的属性。

例如：

公共类用户{ public int UserId { get；set；}公共字符串名称{ get；set；}

- Core
      \Entities <-- Poco's
      \Services <-- Interfaces for services

服务

这将是包含业务逻辑的地方。用户如何验证？我们如何计算订单何时应该自动存档或其他什么？一般来说，我在这里不做任何数据库工作。

存储库

这就是你做基本数据库工作的地方。你说你不使用L2S或EF等，没有问题。我会认真考虑使用微ORM代替，如脱衣舞或海量。

测试

你在做单元测试和集成测试，对吧？我建议在测试框架中使用xUnit或nUnit。

Web应用

这是MVC3应用程序。我建议在您的依赖项注入中使用StructureMap。(您使用的是IoC/DI，对吗？)

你可能一开始就认为->会引起很多项目的关注，对吧？好吧，很容易把它分成两个项目。

1. Web应用
2. 试验项目

核心库、服务、库都以文件夹的形式存在于Web应用程序项目中。

尝试而不是过度设计Visual解决方案。大多数人认为他们需要大量的项目和大量的抽象。因为他们认为每个人都在做这件事，这是正确的。嗯，这个思路是2000年代初的。而在2012年--自那以后，大量的shiz发生了变化。

尝试使用DI/IoJ、NuGet将这些库下载到您的解决方案中，使用Micro/M进行数据访问和测试项目。

有几个项目要检查，re:事情是如何安排的：

1. JabbR.net
2. RavenOverflow

Answer 2

1. 也许吧，如果模型需要的话。大多数模型都是具有公共属性的简单dtos。但您也可以轻松地封装其中的一些内容。
2. 不完全同意。存储库是业务对象的集合。它可以从数据库中创建这些对象的实例。
3. 控制器是控制服务器上发生的事情的入口点。读取将将数据从存储库加载到视图模型中，并将视图模型推入视图。写将从存储库加载数据，更新域并保存更改。然后重定向到读取控制器动作。

最重要的是。别想太多建筑了。这种事发生得太多了。开发人员需要干净的代码，实际上使其维护更加复杂，而不是更简单。

无论您是否使用数据库或ORM，您的存储库中都有相同的功能。

Answer 3

我认为从小开始是好的，然后当需要出现时，你开始扩大你的观点，并开始在你需要的时候把它们分开。如果您有两个模型、一个视图和一个表来查询和更新数据库，那么为什么要将您的工作分成20个if项目。

从小开始，让“需要”驱动设计。如果需要在数据库中读取/写入大量表，那么现在可能是开始使用存储库模式的时候了。您现在发现您需要至少10个或更多不同的模型，现在可能是实现包含DTO/模型的库并将它们从web应用程序中删除的时候了。

例如，如果您需要编写单元测试或执行TDD，那么您会发现能够立即模拟存储库、业务和服务层是很有用的。

不过，为了便于论证，我看到了一些类似于以下内容的项目(但大多数项目都不需要这样的分离)：

• web项目；使用服务库和dto库
• 服务库；使用业务层库和dto库
• 业务层库；使用存储库、实体库和dto库
• 存储库；使用实体库
• 实体库
• dto图书馆

其中大部分被进一步分解成单独的库，其中一个包含接口，另一个包含实现等等。我参与过的一些项目有50多个库来分离大部分(如果不是所有的话)，但它总是基于需求或需求。

上述示例的思想是让web应用程序只处理将DTO传递到服务调用并从服务调用中接收DTO的问题。

大多数情况下，您可以使用DTO作为模型，但有时，如果您需要基于几个DTO的平面模型，您可以创建自己的视图-模型作为包装器来平平多个DTO。

服务转到并调用管理器中的方法，传递驻留在业务层库中的DTO。该管理器将使用DTO并将其映射到一个或多个实体，并调用传递这些实体的存储库中的方法。存储库返回管理器用来构造DTO以发送回的实体。

有很多方法可以做到这一点，我相信没有一个是唯一正确的方法。

例如，您可以使用一个依赖注入框架来实现更多的分离和独立。

以上只是一个例子。它可能对一组人很有用，而另一组人则认为这是不可接受的。这取决于许多因素，项目的规模是主要因素之一。

不过，除了所有这些之外，始终要从一个可管理的规模的体系结构开始，当需要更改时，您将不断地进行重构，无论是为了满足单元测试中的模拟，模型的数量在web应用程序中已经变得无法管理，或者现在一个单独的团队必须编写服务层，并且您不希望这样会干扰您的开发，服务层现在可能不得不被不同的UI层所消耗，而不仅仅是web前端，等等……