应用程序的哪些部分未编码？
我认为最明显的例子之一就是数据库凭证，很难对其进行硬编码。而且在大多数情况下，很容易决定是否要对某些东西进行外部化或者编码。对我而言，规则很简单。在以下情况下，应将应用程序的某些部分外部化：

• 它可以并且应该由非开发人员进行更改，但不经常包含在UI中定义的应用程序设置中(数据库凭证，服务URL等)
• 它不需要编程语言，并且似乎不自然地被编码(本地化)

我们有什么要补充的吗？

这与有关spring cfg的问题有点相关。
在我看来，Spring配置似乎不太明显，因为在我的实践中，除开发人员外，从未有人对其进行过修改。而外部化的道路可能会让我们走得更远，到整个项目都在"配置"中，而不是被编码，所以在哪里停止？

因此，如果我们从配置中受益，而没有像在Spring中进行依赖注入配置这样的编码，那么请从这里发布一些示例，以经验为基础。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
而且，如果我们使用spring，则无需重新编译就可以多久更改一次配置？

解决方案

想到路径和服务器名称/地址。

在应用程序的不同部署之间需要做的一切都不同。也就是说，任何特定于环境的东西。

示例包括：

• 数据库连接字符串
• Web或者WCF服务的URL
• 记录配置

我同意两个条件，这就是为什么我：

• 很少将配置文件包含在Windows或者Windows Mobile应用程序中(Web应用程序是)。
• 如果我确实包含一个供最终用户调整的配置文件，那么肯定不是XML。

除了显而易见的变化(路径，服务器，端口等)外，有人认为我们应该能够轻松更改可能合理更改的任何内容，例如，说我们有一个基于业务逻辑运行的通用引擎(规则引擎)。

然后，我们将在"配置文件"上定义规则，该规则最终将不少于使用DSL而非通用语言进行编程。好处是它离域更近，因此更容易且更易于维护，并且我们可以轻松更改可能需要重新构建的内容。

这背后的主要论据是，我们假设永远不会改变的事情总会最终改变，因此我们最好做好准备。

员工的电子邮件/姓名，因为员工可以来来去去...(不过，我们通常应尝试将其排除在应用程序之外)

配置文件应包括：

• 文件路径
• 主机名
• GUI中没有的选项

最后一个有点开放，但是非常重要。我发现预见客户端将来可能要更改的变量非常有用。如果更改很少，我或者他们可以编辑配置文件。如果这成为常见的事情，那么将选项添加到GUI(这不是硬编码的)是微不足道的。

应用程序使用的任何信息都是"数据"，并且可能会有所不同，具体取决于安装位置。像：

• smtp邮件服务器，用于发送电子邮件
• 数据库连接字符串
• 应用程序使用的文件位置/文件夹的路径
• FTP服务器和连接信息
• 用于身份验证的Active Directory服务器
• 应用程序中显示的任何指向外部信息源的链接
• 警告极限值
• 我什至将RegEx筛选器用于限制数据输入字段的允许字符。

我还要添加加密密钥(它们本身应该被加密)...

基本上，经验法则是应用程序在进行常规的功能操作之前需要获得的信息，必须手头准备的数据(即本地数据和未联网的数据)。
请注意，此数据不应动态更改或者大量更改，否则应在数据库中。

使用Spring应用程序，我实际上可以区分两种类型的配置：

• 外部化到属性文件中的，涉及"部署时间"或者"特定于环境"的项目：服务器IP地址/地址，文件系统位置等
• Spring XML配置可以完成很多事情，例如指示整个应用程序结构，通过AOP应用行为等。

我使用Spring在没有GUI(事务开关)的J2SE应用程序中连接所有bean。这样，对于我来说，在每个部署中具有不同的配置(我们在不同的国家/地区运行此东西)非常容易，而不必编写任何不同的代码。
我想拥有的另一件事是，当我使用纯JDBC(或者Spring JDBC)时，将所有SQL语句与代码分开管理。就像在属性文件或者XML之类的文件中一样，有时甚至是将使用该语句的bean中的String属性(当只有一个将使用该语句的bean，例如DAO时)。

我将使用spring JDBC或者vanilla JDBC进行数据持久化，这里我们决定将Java代码中的所有SQL外部化，因此可以更好地在SQL查询调整和优化方面进行管理，我们无需打扰Java代码。