升级.NET应用程序数据层

Question

我为一家开发超大规模数据应用程序的公司工作。该应用程序最初是在十年前创建的，因此迫切需要升级。我被赋予了调查和实施数据层升级的任务。

目前，它使用的系统的业务对象都基于/扩展DataRow对象，即 - 每个对象或多或少与数据库中的一行有关。该应用程序目前不是面向对象的，但是这会导致很多问题，我们希望按照OO方向移动。

因此，我们正在寻找开始使用.NET实体框架并创建一个.edmx文件。这个想法只是将所有的SQL数据库表拖放到.edmx设计器上，并让它创建其相关的数据对象。

现在，在我的脑海里（作为一个面向对象的开发者），我正打算手动创建新的业务对象，并填充它们从的.edmx生成的数据对象从查询新的数据层返回。这将允许使用接口简单分离各个层。

的问题是，老板说，没有足够的时间来改写百元左右的业务对象类，他建议使用的.edmx产生的在整个应用程序数据对象。

在我的脑海里每思说：“不......不创建数据层和整个系统之间的耦合”，但老板说，他已经看到了网上的文章促进这一点。

所以我的问题对你们是这些：（请提供你的答案为1正当理由和2）

1. 这是一个可行的解决方案（即使是短期）？

2. 有没有更好的/替代的解决方案，从生成的数据对象创建单独的业务对象？

3. 有用来创建从生成的数据对象单独的业务对象，而不是手动复制和粘贴一个更好/更简单的方法？

我明白这些问题有点主观，但我已经提供了尽可能多的具体信息，我真的可以做一些关于这个问题的建议。

Answer 1

这是一个常见问题，可能是每个遗留系统人员尝试升级。

我没有看到任何您创建“数百”业务对象并将数据从EF数据对象复制到您的数据的任何一点？您仍然与EF和您的业务对象耦合！

要使用耦合IoC通过，应考虑在数据访问层与业务层之间保持分离。当然，你可以用很少的成本/时间来切换ORM。这是separation of concern的美丽。在软件行业，如果您现在想要降低成本，您可能需要长期支付更多费用（如果您需要再次更改或ORM）。

试着在质量方面与你的老板进行谈判，现在可能有点贵，但从长远看肯定会有所收获。您可以考虑使用EF Code First。在数据访问层设计上，这肯定会比“数据库优先”更好地掌握。

您也可以编码生成器来生成您想要的数据访问层，这样可以节省数百个工时，另外您可以更好地实现模块。我建议你去CodeSmith Generator。有一点学习曲线，但它是值得的。

请记住，分离数据访问不是升级遗留系统的解决方案。在很多情况下，我看到升级和维护核心功能成为世界上最难的工作。除非业务人员在面临失败时决定进行真正的升级，否则没有什么可做的。

尝试确定核心组件，并且DAL必须是要升级的核心组件之一。

Answer 2

当我开始发展我当前的应用程序，我选择使用代码首先，以免产生巨大的EDMX。我读到他们正在对该设计师进行改进（将其拆分等），但实际上，我不想尝试使用edmx，因为我们必须创建100多个对象。

我开发了一个小应用程序来读取表格并为代码优先创建POCO对象（我认为现在有工具可以做到这一点），然后为所有这些对象创建一个表示上下文containsinig DbSet的类。

当我试图将这些对象直接用于前端的MVC应用程序时发现，我得到的序列化问题试图将它们放入具有循环引用问题的网格中（大量使用json序列化）。所以，我选择创建ViewModels，并且在我不需要速度的情况下，使用像AutoMapper这样的工具来映射表< - > ViewModel。在我确实需要速度的情况下（如列表屏幕），我写了实际的linq查询来将结果转换为视图模型对象。我发现的唯一问题是视角模型必须非常平坦。

对于你来说，这不是一个真正的答案，而是通过这个过程的一些经验。

Answer 3

的问题是，老板说，没有足够的时间来 重写百元左右的业务对象类，他使用的.edmx在整个 应用程序生成的数据对象表明 。

1. 这是一个可行的解决方案（甚至短期）？ &
2. 是否有更好的/替代的解决方案来从生成的数据对象中创建单独的业务对象？ &
3. 是否有更好/更简单的方法从生成的数据对象中创建单独的业务对象，而不是手动复制和粘贴？

ANS：你可以尝试Sybase PowerDesigner可以逆向工程和生成C＃代码为您服务。 或者您可以尝试CodeSmith为您生成代码。这些工具节省您的时间。

还有其他的框架，如Developer Express XPO和DataObjects.Net etc ...或LLBLGen Pro你可以试试。这些可以分开你的关注。