应用项目结构问题

我的公司通过向所有客户提供所有功能来解决这个问题。这使得开发更简单，并允许我们花更多的时间来改进产品，而不必花时间处理可选功能的复杂性。

我们有时会遇到客户的轻微抵制，他们想要一个功能更少的便宜版本，但这从来都不是销售问题。

另一方面，如果您向客户销售更便宜的功能更差的版本，他们可能会试图摆脱这些更便宜的版本。这可能会导致他们不喜欢这个软件，因为他们买了便宜的残缺版本。我坚信要尽可能为用户提供最好的产品。

这个建议可能不适合你的个人情况，但你确实说过欢迎任何意见。

每个客户一个版本不是一个好主意。它总有一天会阻碍你的销售。

最好让所有的功能都发布给所有的客户，例如，只维护一个软件，但要用密码锁定。您可以在软件安装时提供一个唯一的许可证号码，以便识别客户(将其名称放在许可证中)，然后根据该许可证号码计算一些密码，以在付费时根据要求解锁某些功能。这个密码可以很容易地通过一个网站自动设置，成本最低。

或者你也可以让所有功能用于测试，但锁定打印或保存-只是为了让客户考虑花一些钱来获得这个"漂亮的附加功能"。

有时候，拥有所有功能往往会创建一个"Gasworks"应用程序。您可能需要一个单独的安装应用程序，以便根据客户的需求定制应用程序。这个架构值得考虑。

即使有了版本控制，维护多个版本也是一场噩梦:例如，仅仅将所有热修复程序移植到以前的版本需要花费大量时间。如果你不需要这样做(因为监管目的/认证版本等)，不要"分支"你的软件。

不，绝对不要为每个客户提供一个项目，您可以为每个客户提供一个解决方案，在该解决方案中，您可以聚合给定设置需求的所有项目。

只是给你一个替代插件架构的选择，这是正确的方法，但通常也相当复杂。

Option1 .

1. 将通用功能放在主项目(Core)

2. 额外的东西，如日历放在单独的DLL项目中(每个功能一个)

3. 创建VS SOLUTIONS，在这里您可以为特定的设置+核心聚合所有项目。因此，customer1将拥有带有Core的customer1解决方案和所有他需要的额外项目，customer2具有Core的解决方案及其额外的东西。

Option2 .

为每个用户设置一个大的设置，并根据其配置/许可启用/禁用用户对附加功能的访问。

根据你的资源，如时间，经验，你的同事，客户，你可以选择一个更适合你的选项。

1基于插件:可能是最好的一个，但它，复杂的，它需要一段时间你熟悉它，如果你从来没有做过类似的东西。

选项1简单快捷，但如果客户端数量和配置延迟，您将陷入规模问题。

选项2是两者之间的平均值，但请注意您的设置维度。

考虑到您在解决方案中引用项目和单元dll的事实，如果您在一个解决方案中修复了Core中的问题，它也会影响所有其他解决方案。

你有几个选择:

• 将"标准功能"放入单独的模块中，这些模块可以被其他版本使用/链接
• 使用"plugin-architecture"动态加载可选功能

除了其他人所说的，还有另一个选项:条件定义。

使用条件编译，你可以用IFDEFS (IFDEF EmployeeCalendar, IFDEF SearchFunction…)包装特定功能的代码。然后，对于每个客户端，您只复制项目文件，并根据您想要包含的功能设置条件定义。

如果客户端想要/支付额外的功能，你只需将其添加到该客户端的项目文件中的条件定义中。

这类似于模块方法(BPL/DLL)，但避免了必须部署/管理额外文件的额外成本。缺点是特性集在编译时是固定的。

使用BPL/DLL，您可以在运行时动态加载额外的模块，但如果这对您的情况不重要，那么条件定义可能是一个不错的选择。

当然，如果你的功能是不容易分离的，那么你最终可以在代码中有很多ifdef，但是你的问题是功能的明确分离，这将是模块的问题。