构建项目和C#中大型winforms应用程序的依赖关系 [英] Structuring projects & dependencies of large winforms applications in C#

问题描述

更新:
这是我访问量最大的问题之一，但我仍然没有真正为我的项目找到令人满意的解决方案.我在另一个问题的答案中读到的一个想法是创建一个工具，该工具可以为您从列表中选择的项目即时"构建解决方案.不过我还没有尝试过.

UPDATE:
This is one of my most-visited questions, and yet I still haven't really found a satisfactory solution for my project. One idea I read in an answer to another question is to create a tool which can build solutions 'on the fly' for projects that you pick from a list. I have yet to try that though.

你如何构建一个非常大的应用程序?

How do you structure a very large application?

• 在一个大解决方案中包含多个小项目/程序集?
• 一些大项目?
• 每个项目一个解决方案?

以及在没有一个解决方案的情况下如何管理依赖项.注意:我是根据经验寻求建议，而不是您在 Google 上找到的答案(我自己可以做到).

And how do you manage dependencies in the case where you don't have one solution. Note: I'm looking for advice based on experience, not answers you found on Google (I can do that myself).

我目前正在开发一个应用程序，它有超过 80 个 dll，每个都有自己的解决方案.管理依赖项几乎是一项全职工作.有一个自定义的内部源代码控制"，具有用于在各处复制依赖项 dll 的附加功能.对我来说似乎是次优解决方案，但有更好的方法吗?我担心，在实践中使用 80 个项目的解决方案会非常粗糙.

I'm currently working on an application which has upward of 80 dlls, each in its own solution. Managing the dependencies is almost a full time job. There is a custom in-house 'source control' with added functionality for copying dependency dlls all over the place. Seems like a sub-optimum solution to me, but is there a better way? Working on a solution with 80 projects would be pretty rough in practice, I fear.

(上下文:winforms，而不是 web)

(Context: winforms, not web)

(如果您认为这是一个不同的问题，请给我留言)

在我看来，两者之间存在相互依赖关系:

It seems to me that there are interdependencies between:

• 应用程序的项目/解决方案结构
• 文件夹/文件结构
• 源代码控制的分支结构(如果您使用分支)

但如果可能的话，我很难将它们分开来单独考虑.

But I have great difficulty separating these out to consider them individually, if that is even possible.

我问了另一个相关的问题 此处.

推荐答案

源代码控制

我们将 20 或 30 个项目构建到 4 或 5 个离散解决方案中.我们正在为 SCM 使用 Subversion.

We have 20 or 30 projects being built into 4 or 5 discrete solutions. We are using Subversion for SCM.

1) 我们在 SVN 中有一个树，其中包含按命名空间和项目名称逻辑组织的所有项目.根目录中有一个 .sln 可以构建它们，但这不是必需的.

1) We have one tree in SVN containing all the projects organised logically by namespace and project name. There is a .sln at the root that will build them all, but that is not a requirement.

2) 对于每个实际的解决方案，我们在 SVN 中有一个新的主干文件夹，其中包含 SVN:对所有必需项目的外部引用，以便它们从主树下的位置进行更新.

2) For each actual solution we have a new trunks folder in SVN with SVN:External references to all the required projects so that they get updated from their locations under the main tree.

3) 在每个解决方案中都有 .sln 文件和一些其他必需的文件，以及该解决方案独有且未跨解决方案共享的任何代码.

3) In each solution is the .sln file plus a few other required files, plus any code that is unique to that solution and not shared across solutions.

拥有许多较小的项目有时会有点痛苦(例如 TortoiseSVN 更新消息会因所有这些外部链接而变得混乱)但确实具有巨大的优势，即依赖项不允许循环，因此我们的 UI 项目依赖在 BO 项目上，但 BO 项目不能引用 UI(也不应该！).

Having many smaller projects is a bit of a pain at times (for example the TortoiseSVN update messages get messy with all those external links) but does have the huge advantage that dependancies are not allowed to be circular, so our UI projects depend on the BO projects but the BO projects cannot reference the UI (and nor should they!).

架构我们已经完全切换到使用 MS SCSF 和 CAB 企业模式来管理我们的各种项目在 Win Forms 界面中组合和交互的方式.我不确定您是否有同样的问题(多个模块需要在通用表单环境中共享空间)，但如果您这样做了，那么这很可能会为您构建和组装解决方案的方式带来一些理智和惯例.

Architecture We have completely switched over to using MS SCSF and CAB enterprise pattern to manage the way our various projects combine and interact in a Win Forms interface. I am unsure if you have the same problems (multiple modules need to share space in a common forms environment) but if you do then this may well bring some sanity and convention to how you architect and assemble your solutions.

我提到因为 SCSF 倾向于将 BO 和 UI 类型的函数合并到同一个模块中，而之前我们保持严格的 3 级策略:

I mention that because SCSF tends to merge BO and UI type functions into the same module, whereas previously we maintained a strict 3 level policy:

FW - 框架代码.功能与软件相关的代码.BO - 业务对象.功能与问题域相关的代码.UI - 与 UI 相关的代码.

FW - Framework code. Code whose function relates to software concerns. BO - Business Objects. Code whose function relates to problem domain concerns. UI - Code which relates to the UI.

在那种情况下，依赖是严格的 UI -> BO -> FW

In that scenario dependancies are strictly UI -> BO -> FW

我们发现即使在使用 SCSF 生成的模块时我们也可以保持该结构，因此世界上一切都很好:-)

We have found that we can maintain that structure even while using SCSF generated modules so all is good in the world :-)

这篇关于构建项目和C#中大型winforms应用程序的依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！