将多个VFP9类转换为C#

Question

首先，我要说的是，自Java在大学期间(我于2005年12月毕业)以来，我一直没有用一种高度面向对象的编程语言进行编程。自从我毕业后，我一直在用FoxPro 2.5 - VFP9编程.现在，我工作的公司正在推动将我们所有的FoxPro应用程序转换为C#。

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

现在听我的问题..。

从设计的角度来看，我们希望我们的新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 DLL H00002_3422551.MSG，这将调用H00002 DLL。

每个H00001、H00002等(总共有575个DLL )将使用基本DLL中的方法。

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

Answer 1

听起来你想要的是一种“插件”式的架构。这允许您在不重新编译主应用程序的情况下插入/更新dll(程序集)。

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

还有相关的。

Answer 2

576个项目和/或解决方案是维护的噩梦。对于一套产品，我的项目要少得多(75个左右)，涉及的解决方案不多。这包括测试、框架组件等，我唯一能掌握的方法是通过严格的命名/路径约定、源代码管理和自动化脚本。

说到测试，你应该计划单元测试(绿地开发提供了一个很好的机会，不要错过这个机会)。测试是在一个单独的项目中进行的；这也是为什么每个类不应该被赋予自己的程序集的另一个原因。理论上你可以把你的项目数量翻一番。

首先，我将使用逻辑分离的项目(例如，按函数/依赖关系分解，并为每个库添加一个测试项目)。

源代码管理消除了对团队成员之间冲突的任何关注。如果在启动和运行源代码管理方面存在内部挑战，请查看：http://tfs.visualstudio.com/。设置是难以置信的简单，它是免费的多达5个用户。

如果您最终确实需要更大程度地断开项目之间的连接，您可能需要考虑使用带有NuGet包的局部存储库来隔离/版本不同的离散组件。这不是我的第一步，但这是一个值得记住的选择。

从评论中可以看出，您目前正在执行自治单元的日常部署。

1. 这看起来很冒险。这能由配置/数据而不是代码更改来驱动吗？
2. 576个完全自治的单元似乎是应用程序设计中的一个问题(例如重用？)
3. 假设每天都必须部署新代码，也许一种脚本语言+ DLR可以使这更容易。c#的动态编译也是可能的。