将多个 VFP9 类转换为 C#答案

【问题标题】：Converting multiple VFP9 classes to C#将多个 VFP9 类转换为 C#
【发布时间】：2013-09-04 16:39:00
【问题描述】：

首先我要说的是，自从大学 Java（我于 2005 年 12 月毕业）以来，我就没有使用过大量的 OO 编程语言进行编程。自从我毕业以来，我一直在使用 FoxPro 2.5 - VFP9 进行编程。现在，我工作的公司正在推动将我们所有的 FoxPro 应用程序转换为 C#。

我在这个项目中的一部分是转换我们的报告解析应用程序。在 VFP9 中，它由 5-6 个表单组成（由于我们创建了一个新的 C# 前端来替换它，因此没有一个会被继承），一个包含我们所有标准方法的单个 Base 类，以及大约 575 个单独的 parser 类（其中一些只设置一些解析器特定的变量/属性并调用所需的基类）。一些解析器包含他们自己的自定义方法，这些方法仍然使用基本方法和全局属性并与之交互。

现在我的问题...

从设计的角度来看，我们希望新的 C# 前端生成多个可执行文件（3-5 个 EXE），这些可执行文件将调用我们新的 C# 基础/解析器类库 (DLL)。我最初的想法是我将拥有一个包含 Base_Code.cs 和其他 575 个 parser.cs 文件（H1.cs、H2.cs、H3.cs 等）的解决方案/项目。但是，我们需要能够独立于其他文件构建每个 .cs 文件，因为我可能会在我的同事更新 H1.cs 时更新 Base_Code.cs。

如何最好地构建它？我是保留一个解决方案但创建 576 个项目，还是创建 576 个解决方案都使用与另一个团队目前正在尝试的相同命名空间？

我们在整个基本代码和每个解析器（这些将从前端应用程序传入）中使用了几个全局变量/属性，例如文件路径、文件名等，它们将是静态的，因此需要在考虑设计时也要考虑到。

编辑示例**

C# 前端基本上是一个排队系统和文件/状态查看器。这个前端对我们全天收集的报告进行“排队”。列表顶部的报告确定需要什么 DLL。前端应用程序和 DLL 是完全独立的。

示例：H00001_2342318.MSG - 这将调用 H00001 DLL H00002_3422551.MSG - 这将调用 H00002 DLL

每个 H00001、H00002 等（总共 575 个 DLL）都将使用 BASE DLL 中的方法。

如果我必须更新 H00001 DLL，我需要这样做，而不必重建所有 575 个 DLL。

【问题讨论】：

"we need the capability to build each .cs file independently of the others as I may be updating the Base_Code.cs while my co-worker is updating the H1.cs" - 我不确定我是否遵循这种推理。我看不出团队成员不能根据需要从源代码控制修改文件（即使是同一个文件）的任何原因。当需要进行新构建时，请从源代码控制中重新构建。为什么每个文件都必须是自己的程序集？
576 个项目和 576 个程序集，每个项目都有一个类是吨的维护开销，等等，就像@David 所说，对我来说，这听起来像是 1 个解决方案 1 个项目 1 个程序集并正确使用源代码管理。
@David 我个人从未使用过源代码控制，但我理解它的目的，并且我同意这可能是最好的方法。但是，我们没有任何源代码控制（尽管我们已经提出要求并且我相信其他部门正在使用 TFS 或 SourceSafe）。不幸的是，这家公司获得任何东西的速度和国会一样慢，所以不能保证我们很快就会拥有它。
@Spoon82：即使没有源代码控制，我仍然看不到将每个类放入其自己的编译程序集中的理由。如果问题的根源在于缺乏源代码控制，那么解决方案就是使用源代码控制。解决方案是不将代码模糊到您确信自己不需要源代码控制的程度。这并不能解决问题，只会产生另一个问题。老实说，在不了解应用程序的情况下，我没有看到任何令人信服的理由说明为什么所有代码都不应该在一个项目中。或者最多一个应用程序项目和一个业务逻辑项目。
@David - 让我试着更清楚地解释一下为什么我们希望每个文件都单独构建。正如我们现在的 VFP 应用程序一样，我们有一个每天运行的进程，并使用任何新的/更新的类（基本或单独的解析器）更新我们的解析应用程序。它基本上是将文件从我们的源网络复制到我们的生产网络。我们希望所有这些都保持不变。所以我想我需要知道如果我重建一个有 575 个文件但只有 1 个文件被修改的项目，那么所有 575 个文件现在是否都将今天的日期作为最后修改日期？

标签： c# visual-foxpro

【解决方案1】：

听起来您想要的是一种“插件”式架构。这使您无需重新编译主应用程序即可插入/更新 dll（程序集）。

例如http://code.msdn.microsoft.com/windowsdesktop/Creating-a-simple-plugin-b6174b62

和相关的。

【讨论】：

我相信我们的前端应用程序将使用插件架构。我在这个项目中的一部分是实际的 DLL 本身。

【解决方案2】：

576 个项目和/或解决方案是维护的噩梦。对于一整套产品，我在不到十几个解决方案中的项目要少得多（大约 75 个）。这包括测试、框架组件等，而我掌握它的唯一方法是通过严格的命名/路径约定、源代码控制和自动化脚本。

说到测试，您应该为单元测试做计划（新建开发为此提供了绝佳的机会；不要错过机会）。测试在一个单独的项目中进行；这是每个类不应该有自己的程序集的另一个原因。理论上，您可以将项目数量翻倍。

我会从一个具有逻辑分离项目的单一解决方案开始（例如，按功能/依赖关系分解事物，并为每个库添加一个测试项目）。

源代码控制消除了对团队成员之间冲突的任何担忧。如果您在启动和运行源代码控制方面遇到内部挑战，请查看 Team Foundation Services Online：http://tfs.visualstudio.com/。设置非常简单，最多可供 5 位用户免费使用。

如果您最终需要在项目之间实现更大的断开连接，您可能需要考虑使用带有 local repository 的 NuGet 包来隔离/版本化不同的离散组件。这不是我的第一步，但值得牢记。

从 cmets 看来，您目前正在执行自治单元的日常部署。

这似乎有风险。这可以通过配置/数据而不是代码更改来驱动吗？
576 个完全自治的单元似乎是应用程序设计的问题（例如重用？）
假设必须每天部署新代码，也许脚本语言 + DLR 可以使这更容易。 c#的动态编译也是一种可能。

【讨论】：

感谢您的回复！每个解析器都是独立的，因为它有自己的变量要设置，并且可能有自己的报告要解析。基本上，我们是一家医疗计费软件公司。我的团队接受我们从付款人那里收到的报告（目前有 575 个：例如 - 蓝十字/AL 的蓝盾），我们必须拆分这些报告并将它们解析回每个单独的站点（例如 - 美国医疗中心）。每个付款人都可能有自己的报告要解析，因此我们必须为该解析器编写自定义报告。我们尝试将尽可能多的可重用代码放入我们的单一基础解析器中！
这是有道理的。根据这些单独的解析器的大小，动态编译可能会对您有所帮助。我有一个应用程序，其中 c# sn-ps 存储在数据库中（可从 UI 配置）并在运行时编译/缓存。这非常灵活，但最适用于较小（
另一个想法：如果您确实为每个付款人创建了单独的程序集，请不要将它们放在一个解决方案中。 VS 和各种插件执行解决方案范围的操作，如果每个解析器之间没有关系，您可能会经历显着的减速而没有任何好处。也许每个字母的解决方案。
我已经用示例更新了我的原始帖子。我需要指出，将使用 DLL 的应用程序是一个完全独立的解决方案/项目。我的团队将维护 DLL，所以我认为动态编译不会对我的工作有所帮助。