.net - 升级 .NET 应用程序数据层

Question

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

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

因此，我们希望开始使用 .NET `Entity Framework' 并创建一个 .edmx 文件。这个想法只是将所有 SQL 数据库表拖到 .edmx 设计器上，并让它创建相关的数据对象。

现在在我的脑海中（作为 OO 开发人员），我计划手动创建新的业务对象，并从新数据层中的查询返回的 .edmx 生成的数据对象中填充它们。这将允许使用接口简单地分离各个层。

问题是老板说没有足够的时间来重写大约一百个业务对象类，他建议在整个应用程序中使用 .edmx 生成的数据对象。

我脑海中的每一个念头都在说“不……不要在数据层和整个系统之间建立那种耦合”，但老板说他在网上看到过宣传这一点的文章。

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

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

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

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

我知道这些问题有些主观，但我已经提供了尽可能多的具体信息，我真的可以就这个主题提出一些建议。

Answer 1

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

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

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

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

Answer 2

这是人们尝试升级的每个遗留系统都会遇到的一个常见问题。

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

IoC在您可以考虑将数据访问层与业务层分离的情况下，应使用耦合通过。并且绝对可以以很少的成本/时间切换 ORM。这就是美separation of concern。

在软件行业，如果你现在想降低成本，从长远来看，你可能需要付出更多的代价（如果你需要再次更改或 ORM）。

尝试与您的老板就质量进行谈判，这现在可能有点贵，但从长远来看肯定会有所收获。

在您的情况下，您可以考虑EF Code First. 这肯定会让您在数据访问层设计上比“数据库优先”更好地掌握。

您还可以编写代码生成器以按照您想要的方式生成数据访问层，这将节省数百个工时，而且您可以获得更好的模块实现。我建议你去 CodeSmith Generator。有一点学习曲线，但这是值得的。

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

尝试识别核心组件，DAL 必须是其中之一才能升级。

Answer 3

问题是老板说没有足够的时间来重写大约一百个业务对象类，他建议在整个应用程序中使用 .edmx 生成的数据对象。

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

ANS：您可以尝试Sybase PowerDesigner，它可以为您进行逆向工程并生成 C# 代码。或者您可以尝试CodeSmith 为您生成代码。这些工具可以节省您的时间。

还有其他框架，如Developer Express XPO和DataObjects.Net等...或LLBLGen Pro，您可以尝试。这些可以分离您的关注点。