我们应该以什么顺序实施Asp.Net Mvc App

Question

这可能是一个奇怪的问题，但我只是想使用Asp.Net MVC启动一个新的中型WebApplication。

每个人都有自己的解决方法，但总会有一些做法。

使用Asp.Net Forms Application时，我总是按照以下顺序工作

• 数据库
• 数据访问层（LinqToSql / Ado.Net实体等）
• BLL（业务逻辑层+业务对象）
• 前端（表格，设计等）
• 身份验证，测试（集成）等等

（并行单元测试从BLL开始）

现在我已经完成了MVC书籍和教程，并即将开始使用Application。 数据库已经存在。我将使用LinqToSql for DAL（Model（s））。

我应该遵循什么顺序来实施模型，查看和控制器。我很困惑，因为所有教程都有不同的方法。

像。一些从路由表开始，一些从Controllers Component开始，然后触摸Views，然后建议将逻辑转换为模型，“如果控制器保持增长”。

一些教导用于控制器集 - ＆gt;查看 - ＆gt;模型，适用于规范中的每个流程。

我不确定什么是正确的方法。对你用来实现组件/阶段的顺序说一句话真是太好了。我也不确定开始进行单元测试的阶段。

我试图让自己清楚，请问是否不确定，如果您觉得更好，欢迎您编辑标题或帖子。

注意：将使用C＃，Sql Server 2005，JQuery，CSS，Visual Studio 2008以及两个测试版和预期的多个版本（组件）的团队。 感谢

Answer 1

我倾向于从用户界面开始并向后工作。这样我就可以在构建应用程序时与用户和业务分析师合作。我概述了一般过程in this post.

Answer 2

这取决于。

1. 从数据库开始，如果你已经有了一个，这是应用程序的重要组成部分。在这种情况下使用实体框架，因为它更加以数据为中心。
2. 如果您有复杂的用户界面和可以为您提供反馈的用户，请从用户界面开始。
3. 如果业务逻辑是王者，UI是二等公民，则从实体开始。这将有助于TDD / DDD等。

我认为你可以结合2/3并在某个时候整合它们。如果你基于另一个（域对象上的UI，反之亦然），它们可能会相互影响，这不是一件好事。例如，我曾经在域实体之后设计我的ViewModel，并且导致了继承了许多域实体设计的复杂视图/视图模型。

独立完成UI将有助于快速反馈和精心设计的视图和模型。独立完成域级将有助于保持坚实的核心设计。独立地执行两者将为您提供2个视点，就像立体视觉一样，可以提供有关整个画面的更多详细信息。这里的关键是域与UI开发人员和客户之间的沟通。

Answer 3

ASP.NET MVC的真正好处是您可以利用测试驱动设计来非常干净地构建解决方案;所以我建议你从测试开始然后向后移动。

http://weblogs.asp.net/shijuvarghese/archive/2009/07/22/introduction-to-test-driven-development-with-asp-net-mvc.aspx

http://www.wrox.com/WileyCDA/WroxTitle/ASP-NET-MVC-1-0-Test-Driven-Development-Problem-Design-Solution.productCd-0470447621.html

http://elijahmanor.com/webdevdotnet/post/ASPNET-MVC-10-TDD-Book-Review.aspx

Answer 4

当与我的团队成员坐下来并确定他们分配给他们的一部分功能的组成部分时，他们倾向于从上到下工作，因为他们通过定义他们通过该方法所需的内容而感觉更舒服。

我们采用TDD方法进行开发，在编写测试时，开发人员通常首先为其新的控制器操作编写单元测试，并指示其行为应该是什么，并从中通常计算出所需的依赖项。

这可能涉及创建新的类/方法，他们这样做以及创建接口并将接口传递到控制器（大量使用IOC）。

这为他们提供了编写测试的下一级接口，然后采用相同的方法编写测试，计算出任何必要的依赖关系（并在必要时创建它们）。

测试仍然可以针对这些接口的模拟版本编写，因此在您还针对这些接口编写测试之前，无需编写实现。

这意味着我们从上到下有100％的覆盖率，结果往往是一个经过深思熟虑的问题解决方案。

当我遇到一个问题时，我会经常从底部开始，因为我已经将它全部映射到我的头脑和纸上，但我可以看到上述方法的好处 - 不太可能最终陷入困境YAGNI陷阱，你最终只得到你需要的代码。