首先我想引用这篇文章：在MVC应用程序中将实体框架数据模型放在哪里？具体的例子
Where to put Entity Framework Data Model in MVC application?
我的EDMX将在它7-10表。不多。
问题是我必须建立我的模型，我正在与[让我们说] 4表。 所以我问自己：这些表是真正的模型表示，将edmx文件放在“Models”文件夹中是否正确，我应该如何命名这个CONTAINER模型？
或者10个表格足以创建一个新项目？如何调用该项目？ .DataAccess？如何命名edmx文件？
我没有那么多的MVC和EF经验，我正试图找出那里的最佳做法。
更新：This后告诉我不要把它放在Models文件夹：“这个模型应该从后端数据存储技术来分离尽可能。”
个人我的MVC项目（无论尺寸如何）由以下最低限度的：
这种结构似乎工作得很好的它将业务逻辑从存储和显示中分离出来。
您绝对不希望将EDMX放置在模型文件夹中，因为它是为视图模型保留的。最佳实践认为，视图模型应完全与存储实体断开连接。
就命名EDMX而言，我通常将它命名为项目的短名称，更重要的是让EDMX的名称空间正确，以便您的模型位于正确的命名空间位置。
我的回复基于Silverlight，我明白它有点偏离了上下文，因为您是从MVC的角度来问的。但请允许我说明，我把我的EDMX
-Widgets。这些都是与多个XAML页面多个UI项目
-UI逻辑是重策划每一个部件和一个主用户界面
- 查看 - 模型XAML页面。这些几乎等同于MVC中的控制器。我使用XAML直接绑定到View-Models。示例QuotationItemModel.vb和xyz.vb等。多个XAML页面可能共享1个虚拟机。
-XAML页面假设按照实现视图模型使用命令绑定。示例按钮点击被路由到VM。我没有做到这一点，因为UI协调逻辑（来自另一个UI架构师）干扰我的委托命令（CanExecute，Execute Func（Of Object，Boolean）Action（Of Object））导致第一级堆栈溢出小部件的点击事件。）
-Model。这里只有一个功能。她的工作将一个代理挂钩到web服务异步调用完成事件，然后触发web服务。 Deletegate的实现实际上回到了View-Model中，即QuotationItemModel.vb中，而不是在Model中。 Model.vb中只有一个函数 - Model中没有其他逻辑。即Model.vb决定端点，http绑定，WCF填充
- 在此解决方案中没有任何EDMX。模型也对数据库一无所知。
WCF实现。重量轻。再一次功能。只有运营合同。
仅将业务对象传入第三个项目的代码。
EDMX的连接字符串在此处配置并传递给第三个项目。
没有其他的逻辑。
没有EDMX认识任何
-Begins用一个简单的工厂委托逻辑和调用类
-Begins与简单工厂的逻辑变得很沉重的后端。使用设计模式来缓解维护问题。从这里，模式可以纵横交错命令，策略，或抽象类型之间的交叉等等等等
-The EDMX的设计是完全清楚，该层
- 商业对象在逻辑方式与EDMX
相互作用 - 我在这里执行LINQ to Entities或参数化查询
- 此层由业务逻辑组成，例如在发出索赔事务之前必须存在承保ID。或者是基于服务器日期的报价单的运行编号顺序。 etc等
- 有一些业务对象到实体的手动映射。潜在的繁琐，但并非总是
-Result传回的XML
第三个项目，很可能是分离的溶液隔着其他轻量级web服务，生产3层架构的准备。然后我会在这个纯粹的层上产生我自己的连接字符串给EDMX。但我现在更像是'2.5'二层架构。我在中间层的web配置中羞怯地暴露连接字符串。体系结构意味着完全拥有另一个硬件平台。在问题空间即用户界面，通信和业务领域，层是域驱动设计的分离。从技术上讲，SQL Server的数据库（超越EDMX）可以很好地坐在另一个架构上，即Windows Azure
我在这里看到的优点和缺点。请温和地提出任何批评，我真的是新的分层。
缺点 没有公开数据合同，当用业务对象和合同的语言进行通信时，我的UI是盲目的。以前这很容易通过在WCF层中使用EDMX来实现。 我现在使用Xelement来表示共享业务对象。但是我仍然需要找到一种暴露数据合同而不暴露数据库内部的方法。目前，我本能地知道并编写我的Xelements中的数据库字段。
这可能就像静音绑定到后端EDMX。沉默有时是不好的，因为如果我得到一个没有数据的专栏，有很多怀疑的原因。没有任何东西不能通过传回XML结果的错误消息来解决。用我的想象力。
版本控制的机制很弱。也许新客户端与单独的操作合同进行交互，以无声重定向到后端2.0版，而现有客户端则利用后端版1.0。这可能意味着您现在应该分别为每个旧数据库和新数据库分别使用2个EDMX
优点 极端解耦。我可以删除/重建EDMX和UI，WCF仍然编译。只有我的第三个解决方案会在这个极端的测试工作中遇到编译错误。
从silverlight UI，触发和与Microsoft Report Viewer报告的通信共享与UI调用的完全相同的类。无论如何，没有“额外的报告web服务功能”。无论用户界面要求的EDMX +逻辑完全相同 - 除非我不选择它。 PS：Silverlight通过查询字符串将过滤条件传递给报告。
该报告再次，不知道的EDMX。例如，如果我从后端删除EDMX，然后更新报表项目中的数据连接，并且报表项目仍然编译时没有问题。
准备迁移到多架构而不会流泪。季节性负载平衡，客户群增加等可能会引发对架构的投资。
业务逻辑的可重用性。例如，如果老板厌倦了Silverlight，我只需要将UI业务对象重新编码为JSON？在HTML 5之下。除了新的要求之外，对业务逻辑没有任何改变。例如，扩展到人寿保险以与现有的一般保险共存，这是一个目前在Silverlight中编码的模块。在HTML 5中设想人生保险，并且仍然与相同的后端共存。同样，原因是因为两个前端都不知道EDMX，我只需要关注从新技术内部构建数据合同。
意外（我是新的分层真的！）副作用。我可能可以测试我的后端与UI分开。这反过来操纵LINQ to Entity（即EDMX）。很酷的单元测试。
更新业务逻辑不影响对IIS（中间层）的新部署，除了可能涉及到版本控制时。
反正这里离有才华的软件架构师杨雪姬
分层架构的示例的分层应用解决方案的指导。您要下载的样本中NET
http://layersample.codeplex.com/
http://layerguidance.codeplex.com/
通知，有过共同的后端，其中EDMX生活和睡眠在不同技术的多个UI的聪明才智。此外，在Windows工作流的基础上，根据需要有选择地调用。您可以看到Serena放置EDMX的位置，并且您可以在其中使用可行的运行代码。纯粹的幸福。
什么意思是正确的命名空间位置？如果我想彻底断开EDMX，我认为这意味着一个独立的项目。所以我称这个项目为AppName.DataAccess。所以EDMX实体将有类似AppName.DataAccess.Entities的东西。 – timmkrause 2012-03-16 11:11:32
是的，这就是我的意思，你需要确保你选择的EDMX的名称空间映射到AppName.DataAccess的某处，否则它不会有多大意义 – 2012-03-16 12:07:20
你可以解释数据，逻辑和网站更深一点？我来自3层Web Forms项目（DataAccess，BusinessObjects，WebApp）。 “网站”是您的实际MVC项目吗？而所有这些独立的项目？ – timmkrause 2012-03-16 15:31:39