我为一家开发大规模数据应用程序的公司工作。该应用程序最初是在十年前创建的，因此迫切需要升级。我被赋予了调查和实施数据层升级的任务。
目前，它使用的业务对象系统都基于/ extend DataRow对象，即每个对象或多或少与数据库中的一行相关。该应用程序目前不是面向对象的，但这会导致许多问题，我们希望在OO方向上移动。
所以我们希望开始使用.NET`Entity Framework'并创建一个.edmx文件。这个想法只是将所有SQL数据库表拖到.edmx设计器上，让它创建相关的数据对象。
现在我（作为OO开发人员），我计划手动创建新的业务对象，并从新数据层中的查询返回的.edmx生成的数据对象中填充它们。这将允许使用界面简单地分离各种层。
问题在于老板说没有足够的时间来重写大约一百个业务对象类，他建议在整个应用程序中使用.edmx生成的数据对象。
我心中的每一个想法都说'不......不要在数据层和整个系统之间建立联系'，但是老板说他已经看过在线宣传这一点的文章。
所以我对你们的问题是这些:(请提供你对1和2的答案的正当理由）
这是一个可行的解决方案（即使是短期的）吗？
是否有更好的/替代解决方案从生成的数据对象创建单独的业务对象？
是否有更好/更简单的方法从生成的数据对象创建单独的业务对象，而不是手动复制和粘贴？
我知道这些问题有些主观，但我提供了尽可能多的具体信息，我可以就这个问题提供一些建议。
答案 0 :(得分：0)
当我开始开发我当前的应用程序时，我选择使用Code First，以免创建一个巨大的edmx。我读到他们正在对该设计师进行改进（将其拆分等）但事实上，我不想尝试使用edmx，因为我们必须创建100多个对象。
我开发了一个小应用程序来读取表并为代码优先创建POCO对象（我认为现在有工具可以执行此操作），然后创建一个表示所有这些对象的包含内容DbSet的类。
当我尝试将这些对象直接用于前端的MVC应用程序时，我发现我发现序列化问题试图将它们放入带有循环引用问题的网格（大量使用json序列化）中。因此，我选择创建ViewModel，在我不需要速度的情况下，使用AutoMapper之类的工具来映射Table＆lt; - ＆gt;视图模型。在我确实需要速度的情况下（如列表屏幕），我编写了实际的linq查询以将结果转换为视图模型对象。我发现的唯一问题是视图模型必须非常扁平。
对你来说不是一个真正的答案，而是经历过这个的经验。
答案 1 :(得分：0)
这可能是每个人们尝试升级的旧系统都会遇到的一个常见问题。
我没有看到您创建“数百个”业务对象并将数据从EF数据对象复制到您的数据中的任何意义吗？您仍在与EF和您的业务对象耦合！
如果要考虑与业务层保持数据访问层的分离，则应使用耦合IoC来传递。绝对可以用很少的成本/时间来切换ORM。这是separation of concern的美丽。
在软件行业，如果你想现在降低成本，你可能需要长期支付更多费用（如果你需要再次更改或ORM）。
尝试在质量方面与老板谈判，这可能有点贵，但从长远来看肯定会有所收获。
在您的情况下，您可以考虑EF Code First。这肯定会比数据访问层设计中的“数据库优先”更好地掌握。
您也可以编写生成器来生成您想要的数据访问层，这将节省数百个工时，此外您还可以更好地实现模块。我建议你去CodeSmith Generator。有一点学习曲线，但值得。
请记住，分离数据访问不是升级旧系统的解决方案。在许多情况下，我已经看到升级和维护核心功能成为世界上最难的工作。除非商界人士在面临失败时决定进行真正的升级，否则没什么可做的。
尝试识别核心组件，然后DAL必须是要升级的组件之一。
答案 2 :(得分：0)
问题是老板说没有足够的时间 他建议重写大约一百个业务对象类 在整个过程中使用.edmx生成的数据对象 应用
ANS：您可以尝试Sybase PowerDesigner，它可以为您进行反向工程和生成C＃代码。 或者您可以尝试CodeSmith为您生成代码。这些工具可以节省您的时间。
还有其他框架，例如Developer Express XPO和DataObjects.Net等......或LLBLGen Pro您可以尝试。这可以将您的问题分开。