0

我正处于 WinForms 产品重写的早期阶段，我正在尝试确定实施新解决方案结构的“最佳”策略。当前的解决方案包含 50 多个项目，并且（大部分）它包含运行应用程序所需的所有逻辑。一些项目确实与存在于单独的“框架”解决方案中的项目有依赖关系，但这也正在被替换/修改。

正如我所说，当前的解决方案产生了一个 WinForms 产品。此外，一切都紧密耦合在一起，从前到后。此外，除了我们的 WinForms 产品之外，我们还希望开始提供 Web / 移动解决方案。由于所需的更改，我正在考虑将其分解为几个单独的解决方案。详情如下。

  • Product.Framework 解决方案变为 Product.Core - 一组共享的程序集，包含通用接口、枚举、结构、“助手”等。
  • Product.Windows - MVC 模式。包含运行 WinForms 产品所需的所有视图和业务逻辑。
  • Product.Web - MVC 模式。包含运行 Web 产品所需的所有视图和业务逻辑。
  • Product.Services - 可托管的 WCF 服务。包含 Web/Win/Mobile 调用底层 DAL 的公共服务层。

这是我正在寻找健全性检查的地方：我计划在 WinForms 和 Web 项目中实现 DI/IoC（我不太担心注入 WCF 服务）；在我看来，在 Product.Core 解决方案中拥有所有具体实体（数据库表的表示）和服务的接口是有意义的。我可能需要对 Web 和 Winforms 解决方案中的 Product.Services 的唯一参考是向容器注册具体类型。

这有意义吗？有什么我忽略的明显的东西吗？感谢您的任何反馈！

4

2 回答 2

2

我思考解决方案的方式是“运行我的程序所需的所有东西”。在您的情况下，您的 WinForms 应用程序是最后一步。目标是能够运行该项目的输出可执行文件。因此，解决方案应该包含从头开始构建该可执行文件所需的每个项目。您最不希望的事情是让新开发人员必须从版本控制中检查您的源代码，然后必须使用部落知识来确定哪些解决方案需要以何种顺序构建，然后如何将它们捆绑在一起。

现在您提到您可能会添加更多的最后一步应用程序，例如 Web 应用程序。假设您的 WinForms 应用程序的依赖项与您的 Web 应用程序相似，我认为您应该将 Web 应用程序添加到与您的 WinForms 应用程序相同的解决方案中。但是，有时为每个解决方案提供不同的解决方案，然后让每个解决方案引用一组类似的项目是有意义的。

要记住的关键事项之一是，当引入项目依赖项时，您将需要更新所有解决方案以具有该新依赖项。这就是为什么我倾向于为大多数事情提供单一解决方案的主要原因。

不要忘记，在 Visual Studio 中，您可以拥有解决方案文件夹来帮助您直观地管理整个解决方案。此外，您可以利用构建配置和依赖关系树，这样当您只需要构建一个最终项目时，构建就不需要编译所有内容。最后，您可以使用“设置启动项目”选项在要使用的最终输出之间切换。

请记住，任何给定的项目都可以很容易地成为多个解决方案的一部分。如果您有一组用于一系列不同产品的核心框架，您可以在每个“产品”解决方案中包含框架项目。如果框架不是主要由使用它的同一团队开发的，您可能需要考虑将框架拆分到一个单独的存储库中，并且只分发输出程序集（将提交到其他存储库并在您的其他解决方案中引用）。

一般来说，我的意见是为所有事情提供一个单一的解决方案，并利用 Visual Studio 的各种功能，因此管理如此庞大而复杂的解决方案并不是很痛苦。我建议反对的一件事是构建一个解决方案取决于另一个解决方案的构建输出。如果您这样做，这两个项目应位于不同的存储库中，并且应根据需要复制和提交构建输出（基本上将输出视为第 3 方库）。

于 2013-10-19T23:35:41.677 回答
0

这里没有“最佳”答案。这是您的问题的观察结果：为什么您需要所有具体实体的接口？这些似乎只是数据模型类。除非您正在寻找模拟这些类或编写可以对一类类进行操作的通用方法（或类），例如实现 IEntity 接口的所有数据模型类，以便您可以通过数据约束您的通用方法/类模型类型。例子：

public void MyGenericMethod<T>(T t) : where T:IEntity{ // do something}

听起来您正在进行的重构/重组将对您所从事的业务产生重大影响，并且现在做出的设计/架构决策将需要随着业务的发展而可持续。我强烈建议让架构师参与到这个过程中，他可以理解业务的需求和性质，并相应地提出一个游戏计划。

于 2013-10-19T23:18:07.963 回答