现在我想在现有的数据库上使用ASP.NET MVC开发一个Web应用程序，我的目标是高可测试性。现有数据库可测试的Asp.net MVC +实体框架体系结构
如果我会在现有数据库的工作，我有一个的.edmx文件在我的解决方案添加到项目中，并与工作。我错了吗？
你能提出一个适用于这种情况的体系结构，包括通用存储库，工作模式单元和依赖注入吗？我搜索了几个小时，但我刚刚在代码第一方法中找到了示例。你知道一篇我可以学习的文章或开源项目吗？
感谢，
您可以使用DDD，一个MVC应用程序（UI），一个WCF作为一个服务层，等你EDMX文件可以产生其他基本的东西有一些关于T4的知识。但是，您需要阅读很多有关该模式的内容，并尝试执行您自己的实现。请记住，EF数据库第一个只是的一种方法技术的数据访问解决方案，尝试审查Code First实施和适应模型第一的方法。
如果我会在现有数据库的工作，我有一个.edmx文件在我的解决方案添加到项目中，并与工作。我错了吗？
是的，当您生成edmx时，您将生成包含数据属性的部分类（即：public partial class Car {...}）。您必须在您自己生成的项目的部分类（公共部分类Car {...}）中添加自己的业务规则。
如果您希望数据库根据您的应用程序数据模型进化，您还可以摆脱自己的edmx并保留数据类。我这种情况下，删除“部分”关键字，只是在项目中移动你生成的类。在应用程序启动时，可以自动迁移数据库（添加或删除列，表）。
对于EF6中的依赖注入，您不能让对象引用另一个对象的接口，或者该关系仅被实体框架忽略。这是一个非常缺失的功能（与NHibernate相比），但它将包含在EF7中。
Dbcontext实现了一个工作模式单元，但是如果您使用多个数据库进行分布式事务，则可以实现自己的例子。
您还可以使用代码优先模型，从现有数据库生成它https://msdn.microsoft.com/en-us/library/jj200620.aspx –
现在我想开发一个在现有数据库上使用ASP.NET MVC的Web应用程序，并且我的目标是高可测性。 [...]您能否为这种情况提出一个架构，包括通用资料库，工作模式单元和依赖注入？
这是差不多一个矛盾。如果你已经有了一个db，你就会遇到问题，因为一切都将由现有的db模式驱动，而不是实际的用例。技术上你想要重写一个应用程序，以便可测试，但我认为你的意思是可维护，同时保留现有数据。
无论您的应用程序需求如何简单或复杂，都无关紧要。如果它是一个CRUD应用程序，即从用户获取数据，验证它然后放入数据库，然后做一些查询，然后事情很容易。
您将每个用例（添加数据，按标准获取数据等）并为其编写一个测试。您不需要存储库，工作单元等。您可以直接使用EF（如果您真的想首先使用ORM）。不要担心嘲笑事物，你的应用程序不再是用于数据库的用户界面，你可以直接用EF与数据库进行测试。
如果CRUD那么KISS。你不需要建筑，不要浪费你的时间，也不要让你的生活复杂化。
如果您的应用程序为业务对象建模（这些业务对象不仅仅是验证器，它们代表概念和域过程），它是随时间演变的事情，它使用业务特定的语言，然后是不同的故事。
然而，这将是途径广为这个职位（和老实说，我高度疑问，你有这种应用程序），因为这将意味着要走的DDD路线，这意味着你必须要了解很多概念和模式之前写任何代码。
虽然OP_can_使用DDD，但事实上已经有一个数据库意味着它将是除DDD之外的所有数据。 – MikeSW