新手 - 真正的asp.net mvc3应用程序的最佳模式和工具

Question

我正在研究如何构建一个mvc 3 Web应用程序，我感到非常困惑。 我花了最近几天阅读DDD，DI，IoC，TDD，EF（以及像城堡映射器，自动化器，温莎，ecc这样的工具），但我需要你的经验来决定我的想法并选择一条路径。

我所知道的：
  - 我想使用MVC 3.0
  - 我想使用EF 4.1或4.2
  - 我暂时不想使用单元测试，但我希望我的项目结构在将来可以通过很少的修改来支持它们。
  - 我想大量使用jQuery（应用程序需要“非常ajax”）
  - 我显然不希望我的控制器和视图直接使用EF对象
  - 我不想写重复的代码（即：如果我有一个带有“FirstName”属性的“person”db表，我不想为软件的每一层创建一个类[dal，bll，ui ，...]具有相同的“人”数据。向数据库添加字段不需要为多个类添加属性）

我想知道的事：
  - 你会使用哪种模式？
  - 在vs2010解决方案中组织项目的最佳方式？
  - 代码优先或数据库优先？
最后但并非最不重要的：是否有可能使用mvc（数据注释，验证，ecc）的所有酷功能与一个严重的ajaxed网站？

当然我不希望得到一个完整详细的答案：我只需要一些指示/帮助/链接就可以朝着正确的方向前进并研究我需要的东西。

提前致谢。

Answer 1

描述您的情况：您想要使用几个框架，并希望尽可能多地使用最佳实践/模式。你会失败的。你的工作是构建工作软件，而不是为你的工作使用尽可能多的模式。

一些“高级建议”：

• DDD：不要这样做！它在某些项目中确实有意义，但通常会像人们想的那样
• TDD：去改善你的设计
• 模式：当您有某种东西或设计理念的解决方案时，请检查是否存在描述该想法的模式，而不是反过来。
• 避免使用某些模式：在某些情况下单身，立面......
• 查看SOLID并阅读Clean Code

Answer 2

好。我见过很多过度设计的应用程序，这使得维护成为一场噩梦。我建议您先关注seperated interface pattern和Single Responsibility Principle。这两个组合使得在将来的版本中易于维护和重构代码。

单元测试也是一件好事。不仅要确保您的应用程序正常运行，还要让您重新考虑您的设计。难以测试的类很可能设计得很糟糕。最常见的解决方案是将班级分解为更小的班级，责任更明确。

我通常在编写单元测试时尝试使用blackbox测试。那就是尽量不要在类中查看测试的用途。如果我无法通过查看合同（方法定义）来弄清楚一个类是如何工作的，我可能不得不重构它。