为EE7应用程序存储参数和数据的最佳方法是什么。我必须向Web应用程序提供会员费或类似数据（可能/可以在一年内多次更改）等信息。应用程序的所有者还应该具有存储这些数据的中心位置以及用于更改它们的应用程序。 提前感谢任何输入
弗兰兹
答案 0 :(得分：1)
这是我们目前正在努力解决的一个问题，因为我们在这里重新构建了一些后端系统，我同意@JB Nizet的评论，它应该存储在数据库中，但是我会尝试添加一些额外的注意事项和选项，以帮助您做出适合您的决定。正确的选择将取决于几个因素。
如果您提供源代码和自动化来构建和部署您的软件，配置可以存储在源代码存储库（即YAML或XML）中，并在构建期间与您的可部署捆绑在一起处理。这有点过时，但肯定是广泛采用的做法，并且大部分都运作良好。
如果要提供可部署的二进制文件，则可以选择几种方法。
首先是在文件系统中有一个预定位置，您的应用程序将在其中查找＆＃34;覆盖＆＃34;配置文件（即用于运行应用程序服务器的用户的主目录）。这样，您可以将二进制可部署文件与配置完全分开，但仍需要为该配置文件构建某种自动化和版本控制，以便客户可以在必要时回滚版本。这也可以是一个或多个配置文件（即，您的应用服务器与应用程序本身的单独文件）。
我们目前正在考虑的选项是拥有一个配置数据库，我们所有的应用程序都可以查询自己的配置。这可以是一个非常简单或复杂的解决方案，具体取决于您的特定需求 - 对于我们这些是内部应用程序，我们自己管理整个生命周期，但我们需要有一个中央存储库，因为我们有数十个服务和应用程序运行大量常见配置密钥，并且独立更新这些密钥可能容易出错。
我们正在寻找一些不同的解决方案，但我肯定不会将配置存储在我们的主数据库中：1）我不认为SQL是配置的最佳存储库，2）我相信我们可以变得更好NoSQL数据库的性能，如果您需要为每个请求加载一些配置密钥，这可能是至关重要的。
如果您需要为您的选项明确定义层次结构，那么MongoDB和CouchDB都可以作为存储配置键的良好候选者，而如果您只需要为配置设置键值存储，则Redis或Memcached是很好的选择（更快）比基于文件的）。我们还可能构建一个小应用程序来帮助配置和版本配置并推动对现有/活动服务器的更改，但我们还没有规定所有要求。也有一些OSS解决方案可能适合您，虽然其中一些解决方案为我们此时想要实现的目标增加了太多的复杂性。如果您使用的是springframework，请查看Spring Cloud Config Project，这非常有趣且值得研究。
这是一个非常有趣的讨论，如果您对如何实现分布式配置有更多疑问，我非常愿意继续讨论。值得深思的是，这里有一些我个人必备的东西，对我们的新配置架构设计很有帮助：
答案 1 :(得分：0)