我目前正在分配一个项目，其遗留系统的设计方式非常糟糕，并且过于关注数据库设计。我试图整合一个新设计，客户可以一点一点地迁移旧系统。
他们目前正在使用EF 4.1但不是代码第一种方法，实体描述/映射位于edmx文件中。他们每次都要进行逆向工程以扩展模型（首先在数据库中进行更改，然后通过自定义工具将它们向上反映到模型层）。
我想知道的是，如果有人使用过BOTH edmx和代码第一种方法来映射类。知道有缺点吗？
答案 0 :(得分：3)
只有当每种方法都有单独的上下文类型时，才能使用EDMX和代码映射（不能在单一上下文类型中混合使用方法）。这可能是最大的缺点，因为它会导致更复杂的代码和维护。
例如，如果您需要在两种上下文类型中都使用某个实体来将其与新旧代码一起使用，则必须将其映射保持两次。您还必须非常小心不要复制实体类本身=您的代码首先必须使用自定义工具为EDMX生成的类，但如果它们在当前解决方案中不使用POCO则无法实现。
另一个问题是数据库完整性。如果您需要在单个事务中保存对两种上下文类型的更改，则必须使用TransactionScope和distributed transaction = MSDTC（每个上下文实例将处理自己的数据库连接）。
如果您确定将迁移整个系统，您可以考虑首先使用代码而不是EDMX（但要注意代码优先映射和DbContext通常提供更多有限的功能集）。如果你不确定你是否能够完成整个迁移，甚至不要考虑首先使用代码，因为让系统处于半数首先使用代码而一半使用EDMX的状态会使一切变得更糟，更可怕。
确定是理论上有点理论，因为在SW开发中，您唯一可以确定的是需求/情况会发生变化。这意味着应该非常仔细地考虑迁移。
答案 1 :(得分：0)
我也对这个问题感到震惊。我发现你可以为数据库建模并且从模型生成数据库＆＃34;在＆＃34; Ado.NET实体模型项目＆＃34;。
但是您无法在该项目中创建存储过程，您只能从服务器导入存储过程。
但是如果你不想在服务器上创建存储过程，你可以在VS上创建另一个项目，＆＃34; SQl CLR数据库项目＆＃34;并且您可以在该项目中编写存储过程和老虎的代码并将它们部署到服务器。
然后您可以再次从＆＃34; Ado.NET实体模型项目＆＃34;中导入这些存储过程。通过＆＃34; 从数据库更新模型＆＃34;。
同样，您可以使用两种方法（代码优先和模型优先）开发服务器项目
希望这会增加更多内容：）