【问题标题】:What are the different ways to create two very similar software packages in C# [closed]在 C# 中创建两个非常相似的软件包有哪些不同的方法[关闭]
【发布时间】:2016-03-29 21:52:13
【问题描述】:

我正在编写一个软件套件,它本质上由使用 WPF 的 C# .Net 中的两个独立应用程序组成。尽管它们看起来可能有点不同,但它们本质上就像同一软件包的精简版和完整版一样工作。完整版包含精简版的所有功能。

我之前通过创建两个独立的应用程序来实现这一点,它们共享一个所有常用用户控件所在的类库。但我现在想知道这种架构是否有更好的设计。

我什至在考虑创建一个应用程序,并在运行时让它决定要使用哪个版本。

任何有此类问题经验的人都可以为我指出正确的方向。

【问题讨论】:

  • 默认情况下在精简模式下工作并且需要某种授权才能充满的单个应用程序怎么样?现在没有人关心MB。搜索试用版,和我一样的问题(click)。
  • 如果您可以将您的应用程序变成模块化应用程序,那么您可以使用不同的模块(插件)集制作两个版本。
  • 您在第 3 段中的想法听起来不错。在 WPF 中,根据某些全局设置让部分 UI 隐藏或修改自己是相当自然的。您还可以使用大量模板选择器并使用名称为“FooTemplate_Full”和“FooTemplate_Lite”的重复模板——当 XAML 需要 templateName 时,您可以查找 templateName + "_" + App.VersionID 或类似的东西。
  • @Sinatr 这就是我想作为使用共享类库的替代方案。我只是犹豫要不要这样做,因为我觉得这可能是不好的做法。如果精简版的要求发生变化以至于与完整版有很大不同怎么办?然后我会得到大量特定于一个应用程序但与另一个应用程序无关的代码。
  • @Dennis 这对我很有吸引力。我可能会这样做,这感觉像是一个更好的解决方案,然后将两者的所有代码打包到同一个类库中。

标签: c# wpf architecture


【解决方案1】:

保持简单

我的经验法则是尽可能保持解决方案尽可能简单。话虽如此,我会使用与您相同的组合。

通常这样拆分项目:

应用逻辑: CompanyPrefix.ProjectPrefix.CoreCompanyPrefix.ProjectPrefix.Data...等

应用程序CompanyPrefix.ProjectPrefix.ApplicationType.App,所以一些例子:

  1. CompanyPrefix.ProjectPrefix.Web.App
  2. CompanyPrefix.ProjectPrefix.Console.App
  3. CompanyPrefix.ProjectPrefix.Wcf.App

由于您有两个 Wcf 应用程序可能想要执行类似的操作

  1. CompanyPrefix.ProjectPrefix.Wcf.Lite.App
  2. CompanyPrefix.ProjectPrefix.Wcf.App

因此,在此示例中,CompanyPrefix.ProjectPrefix.Wcf.AppCompanyPrefix.ProjectPrefix.Wcf.Lite.App 都指向 CompanyPrefix.ProjectPrefix.Core 或您的业务逻辑所在的任何位置。

关于动态加载程序集

有一种方法可以在运行时动态加载库,但除非您处理的是独立组件的模块化系统,否则建议您不要这样做。

如果你对它下定决心,MSDN 上有很多资源,可能会开始here。关于将程序集加载到当前应用程序域的文章。

提出一个清单

我觉得有用的一件事是想出一份清单,以帮助我在遇到困难时做出决定。通常最终会是这样的:

  1. 这是否具有商业价值
  2. 这是否会使调试更加困难
  3. 与我过去的做法相比,采用新方法的优点和缺点是什么?

这不是我的详尽清单,但说明了这一点。当您有一群人在很大程度上坚持出于个人原因而没有任何基础的选择时,这也很有帮助,以及当您遇到困难时可以使用的工具做出决定并坚持下去

处理应用程序逻辑更改(编写干净的代码)

提出一个过于复杂的“不再需要重新编译整个应用程序”是我过去犯的一个错误。你仍然需要部署和编译一些东西。

处理应用程序变化最重要的是

  1. 有源代码管理代码(最重要的)
  2. 编写干净的代码
  3. 编写测试
  4. 编写文档(我知道没有人喜欢这样做)
  5. 再写一些测试

在处理应用程序更改时,花费您大部分时间的是调试,因此请专注于减少您的时间花在调试上​​trong>而不是花在编译和部署

上的时间

对于部署设置持续集成

如果您有能力设置 CI消除 99% 的麻烦更改应用程序。第一次进行设置会浪费一两天的时间,但这是值得的。

查看TeamCityTravis CI

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-06-09
    • 1970-01-01
    • 2012-02-15
    • 1970-01-01
    • 1970-01-01
    • 2012-07-06
    • 1970-01-01
    相关资源
    最近更新 更多