c# - 需要有关 ASP.NET MVC 3 体系结构的一些指导

Question

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

首先我会说我没有使用 Entity Framework 或任何类型的 ORM——我想直接实现我自己的业务对象和数据访问代码(使用 ADO、SPROCS 等)以确保它们是最佳的，这是个人喜好。这是我努力寻找一致信息的地方，因为大多数信息似乎都与 LINQ to SQL 或 Entity Framework 的使用有关。

我的申请由以下项目构成:

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

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

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

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

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

2.存储库类执行数据访问代码但知道业务对象，这又感觉不对，数据访问代码应该位于它自己的类库中并且对对象一无所知？

3. Controller (在网络层)利用存储库接口(interface)，但为什么呢？它们不应该包含业务逻辑，“模型”或业务对象应该？ Controller 当然不应该包含业务逻辑，所以这也是不对的。我不希望存储库中存在业务逻辑，因为它们正在访问数据库。

我正在努力为应用程序寻找一个优雅的架构，只是一个关于如何实现我自己的对象、我自己的数据访问代码并确保应用程序松散耦合的基本轮廓。任何人都可以给我任何指导吗？

Answer 1

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

例如，项目的结构可以如下:-

核心库

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

例如。

公共(public)类用户 { public int UserId { 得到;放; } 公共(public)字符串名称 { 得到;放; }

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

服务

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

存储库

这是您执行基本数据库操作的地方。你说你没有使用 L2S 或 EF 等。没有问题。我会认真认真地考虑使用 Micro-ORM，比如 Dapper或 Massive .

测试

您正在进行单元和集成测试，对吗？我推荐 xUnit 或 nUnit 作为测试框架。

网络应用

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

一开始您可能会想 -> 项目太多了，对吧？好吧，很容易将它分成两个项目。

1. 网络应用
2. 测试项目

Core Library、Services、Repository 都作为文件夹存在于 Web 应用程序项目中。

尽量不要过度设计 Visual Studio 解决方案。大多数人认为他们需要大量的项目和大量的抽象......因为他们认为其他人都在这样做，而且这是正确的事情。好吧，这种思路是在 2000 年代非常非常早的时候......并且在 2012 年 - 从那时起很多 shiz 都发生了变化。

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

一些项目要检查，关于:事物是如何布局的:

1. JabbR.net
2. RavenOverflow