需要一些关于使用 MVC 2 开始新生活的建议以及在 MVC2 中使用哪些 RAD 工具？

Question

我终于决定搭上 MVC 2 的列车了。 我最近阅读了大量书籍，下面的架构我认为对于大多数商业 Web 应用程序来说已经足够了。

分层架构：-
模型（与数据库通信的层）。 EF4
存储库（与模型通信并包含所有查询的层）
业务层（验证、辅助函数、存储库调用）
控制器（控制应用程序的流程并负责从业务层向视图提供数据。）
视图（UI）

现在我决定为每一层创建一个单独的项目（只是为了尊重关注点分离的困境。虽然我知道这是没有必要的，但我认为这使项目看起来更专业:-)

我正在使用 AutoMetaData 用于验证的 t4 模板。我还遇到过 FluentValidation 但找不到太多相关信息。我应该选择哪一个？

选择哪个视图引擎？
Razor View Engine 一见钟情。但它仍处于测试阶段，我认为找到它的例子并不容易。我说得对吗？
Spark ..我也找不到太多关于它的信息，并且不想在没有人听的时候陷入中间的某个地方寻求帮助......:-(

T4 模板自动生成视图，我可以自定义它们以我想要的方式生成视图？这可以用 razor 和 Spark 实现吗？还是我必须手动创建它们？

如果

我能看到一个基于该项目的项目，我将非常感激。

请让我知道这是否是一个值得遵循的架构。 我对业务层有些困惑，比如这真的有必要吗？

Answer 1

这是一个非常广泛的问题。我决定将 Fluent NHibernate 的自动配置功能用于新建应用程序，并且给我留下了深刻的印象。我的很多同事都使用 CakePHP，只需很少的配置即可生成与 cake 使用的默认约定兼容的数据库模式，这对我们来说非常有用。

Answer 2

我强烈推荐《ASP.NET MVC2 in Action》这本书。本书很好地涵盖了用于创建可维护的 ASP.NET MVC 应用程序的库生态系统。

至于视图引擎的选择，这可以取决于您的背景。我个人更喜欢我的视图看起来尽可能像 HTML，所以我会选择 Spark。另一方面，如果您习惯使用 ASP.NET classic，WebForms 视图引擎可能会让您最快地启动和运行。

Answer 3

<块引用>

请告诉我这是否是一个值得遵循的良好架构？

这是一个很好的开始 - 我建议您添加的唯一一件事是业务逻辑和数据访问之间的抽象层（即：依赖关系反转/注入） - 请参阅此： 依赖倒置简介。

<块引用>

我知道它没有必要，但我认为它使项目看起来更专业:-)

哈！通常你会发现很多“东西”并不是必要的 - 直到它需要的那一刻，那时通常已经太晚了。

重新查看引擎：我自己还是 ASP.NET MVC 的新手，因此不熟悉您所谈论的视图引擎；如果我是你，我会想象一些测试场景，然后尝试用每个产品来解决它们，这样你就可以直接比较它们。通常，您需要采取一些措施才能使试驾变得更加舒适 - 尽管这可能需要时间，但通常是值得的。

编辑：

<块引用>

如果我向我的 PM 推荐这一层并给出上述两个原因，那么我认为他不会接受

首先，PM 通常不是技术主管；您负责解决方案的设计，而不是 PM。这并不罕见，根据我的经验，大多数时候，PM 甚至没有意识到他们正在侵犯你并不存在的地盘。这并不是说我是一个“政治土地掠夺者”，但我只是倾向于考虑“关注点分离”，嗯，我相信你明白。

作为设计师/架构师，您需要解释需求并（考虑业务优先级）提出提供最佳“平台”的解决方案。

<块引用>

（关于 DI）我的问题是，这真的值得吗？

如果你用枪指着我的头，我会说是的，但现实世界要复杂一些。

如果您对这些问题中的任何一个回答“是”，那么使用 DI 更有可能是一个好主意：

• 该系统并非平凡
• 系统的预期寿命超过（不确定此处正确的数字是多少，可能没有） t，所以我打算在两年后在地上放一根木桩。
• 系统和/或其要求是可变的。
• 将工作（BL / DAL）拆分到不同的团队将对项目有利（也许您是分布式团队的一部分）。
• 该系统面向具有多样化技术环境的市场（例如：并非每个人都想使用 MS SQL）。
• 您想要执行质量测试（这会让事情变得更容易）。
• 该系统很大/很复杂，因此可以将功能拆分并放入其他系统中。
• 您希望提供不止一种存储数据的方法（例如免费的基于文件的存储库和收费的数据库驱动的存储库）。
• 业务驱动因素/环境是不稳定的 - 如果他们来找你说“这很棒，但现在我们想提供基于云的版本，你能把它放在 Azure 上吗？”

我还想指出，虽然肯定有一个学习曲线，但它并没有那么大，一旦你跟上速度，你仍然至少会像现在一样快；或者在最坏的情况下，你会花费更长的时间，但你会提供更多的价值（相对较少的努力）。

就涉及多少努力而言......

一次性任务（除了让团队加快速度之外）：

• 编写提供程序加载器或选择 DI 框架。完成此操作后，它将可以在您的所有项目中重复使用。

“新”常见任务（假设您遵循本文中采用的方法）：

• 定义接口（在纸上）- 无论如何，这都是您现在要做的事情，只是您可能没有意识到。基本上它是面向对象设计，但由于它将成为两个或多个包之间的正式接口，因此您需要考虑一下（是的，您仍然可以重构它 - 但理想情况下，接口应该“稳定”并且不会发生太大变化；如果确实发生变化，最好“添加”而不是“删除或更改”现有成员）。
• 编写接口代码。这非常快（几分钟而不是几小时），因为您没有编写任何实现；当你去实现时，你可以使用 IDE 提供的工具来生成基于接口的代码存根。

您现在要做的事情可能会有所不同：

• 实例化一个变量（在您的 BL 类中）来保存提供程序，可能是通过工厂。编写此内容不会花费很长时间（再次强调，几分钟而不是几小时），并且复制、粘贴和复制代码相当简单。在需要时重构。
• 编写DAL代码：应该和以前一样。

Answer 4

有时从代码中学习模式要容易得多：Sharp 架构是 MVC 中良好实践的具体实现，使用 DDD。