在尝试分离我的域层和GUI并研究所有不同的方法时，我一直在问一件事，为什么这这么困难？为什么所有额外的数据代码都是obejct，然后所有额外的属性映射都是复制值的输入和输出等等。这不是一种更容易的方法吗？
然后我想起了我以前使用MS Access开发小型数据库应用程序的时候，Access有Dynaset的概念，基本上Dynaset是一个视图，就像SQL Server视图一样，只是它是一个可更新的视图。因此，MS Access表单将基于View/Dynaset，因此不必知道所涉及的所有单个表的详细信息。对我来说，这听起来像是数据对象模式。既然Access已经有20年的历史了，那么实体框架不应该有类似的Dynaset、View、Mapping工具吗？有没有我不知道的？第三方？
对此有何感想？
如果我理解正确，您可能正在寻找带有POCO实体的实体框架。您可以在模板的在线库中找到它们的模板（当您在项目中添加新项时）。或者，您可以在.edmx设计视图中使用右键单击，选择"添加代码生成项"并选择Fluent Generator。
这些方法创建多个文件，而不是默认的一体式EF生成的文件。一个这样的文件是DbContext（与ObjectContext相反），一个只包含实体（以常规C#对象的形式，没有属性或任何东西，只有普通对象），最后一个包含以流畅规则形式生成的映射。
在此阶段中，可以将实体文件与其模板解除耦合，并将其移动到另一个部件。瞧，你们有独立于外汇基金基础设施的实体。你可以像以前一样传递这些实体的上下文，它会自己进行映射。
或者，您可以使用AutoMapper之类的工具，但您必须手动提供映射，这是一项艰巨的工作，但在某些情况下可能会很好。
好的设计需要工作。如果这很容易，每个人都会自动完成。毕竟，每个人都想做尽可能少的工作。
你抱怨的所有事情都是好的设计过程的一部分，如果你想要一个好的设计，就无法绕过它们。
如果你想走捷径，那么无论如何，跳过它们。这是你的密码。没有什么要求你以任何特定的方式做事。
Access可以做很多事情，因为它是一个桌面应用程序，而不是web应用程序。Web应用程序与桌面应用程序在设计方式、工作方式以及面临的问题方面有着根本的不同。例如，您有一个无状态环境，并且无法将结果集从一个请求保存到另一个请求，这使得人们在Access中认为理所当然的许多事情在web应用程序中无法完成。
具体来说，如果你想使用视图，你可以这样做。如果设计得当，视图是可以更新的，但通常需要只影响视图中一个表的更新语句）。EF也可以处理视图，但它有很多怪癖你必须处理。
数据映射器模式已成为web设计中的一种常见模式，因为它是在层和/或层之间清晰分离关注点的最简单、直接的方法。我建议你想办法让它们在你的开发过程中发挥作用。
MVC也可能不是最适合您使用的框架。听起来你更像是想像使用Access那样构建Web应用程序，在这种情况下，Visual Studio Lightswitch可能是更好的选择。
http://msdn.microsoft.com/en-us/library/ff851953.aspx