1

首先让我说，自从大学 Java（我于 2005 年 12 月毕业）以来，我还没有使用过大量的 OO 编程语言进行编程。自从我毕业以来，我一直在使用 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 H00002_3422551.MSG - 这将调用 H00002 DLL

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

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

4

2 回答 2

0

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

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

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

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

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

从评论中，听起来您目前正在执行自治单元的日常部署。

  1. 这似乎有风险。这可以由配置/数据而不是代码更改驱动吗？

  2. 576 个完全自治的单元似乎是应用程序设计的问题（例如重用？）

  3. 假设必须每天部署新代码，也许脚本语言 + DLR 可以使这更容易。c#的动态编译也是一种可能。

于 2013-09-04T17:14:15.707 回答
0

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

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

和相关的。

于 2013-09-04T16:53:43.993 回答