在哪里保存配置文件

发布于 2024-08-19 15:02:48 字数 447 浏览 10 评论 0原文

我为 PayPal 实施创建了一个新的 C# 项目(非 Web)。我有一堆配置字符串,如下所示,我需要找出最佳的存储方式。我创建的各种包装类正在使用这些字符串。此外,这是一个可以在任何 Web 项目甚至后端中使用的项目。因此,我需要一种很好的方法来处理这些,以便其他应用程序不需要这样做,并将所有这些字符串键集中在我的 PayPal C# 项目中以在那里维护它们。使用我的包装器项目的其他应用程序应该对这些字符串一无所知,或者需要......我的项目负责存储它们。

有了这个,在哪里?我是否在 C# 非 Web 项目中使用 Web.Config?我使用应用程序配置吗?我是否将它们存储在数据库中(不,坏主意)。或者我是否将它们存储为常量,例如 Constants.cs 类中?

我也不知道将它们存储在 Constants 类中是否安全?在我看来,我最好的选择是将 web.config 或某种配置添加到我的非 Web 项目中,然后将它们存储在那里。

I created a new C# Project (non-web) for our PayPal implementation. I have a bunch of config strings such as the following that I need to figure out the best way to store. Various wrapper classes that I created are using these strings. Also, this is a project that can be used in any web project or even back-end. So I need a nice way to sore these so that the other applications don't need to, and centralized all these string keys in my PayPal C# Project to maintain them there. The other apps using my wrapper project should know nothing about these strings or need to...my project takes care of storing them.

With that, where? Do I use a Web.Config in my C# non-web Project? Do I use an App config? Do I store them in the DB (no, bad idea). OR do I store them as constants in for example a Constants.cs class?

I also don't know if storing them in a Constants class is safe? Seems to me my best options here are add a web.config or some kind of config to my non-web project and just store them there.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

作妖 2024-08-26 15:02:48

执行此操作的“标准”.NET 方法是创建一个 app.config 并将它们放置在那里。这些需要复制到调用您正在编写的库项目的任何项目的 web.config 或 app.config 中。

The "standard" .NET way to do this is to create an app.config and place them there. These will need to be copied into the web.config or app.config of any project calling the library project you're writing.

[浮城] 2024-08-26 15:02:48

只需使用 .NET 配置系统 (System.Configuration),无需担心配置设置的存储位置。

如果您的代码是从非 Web 应用程序使用的,则可以在应用程序的 .config 文件中配置这些设置。 Web 应用程序将使用 web.config。

尽管名称不同,app.config 和 web.config 使用相同的 API。

Just use the .NET configuration system (System.Configuration) and don't worry about where the configuration settings are stored.

If your code is used from a non-web application, these setting can be configured in the application's .config file. A web application would use web.config.

Despite dissimilar names, app.config and web.config use the same API.

溺深海 2024-08-26 15:02:48

我们不久前进行了 PayPal 实施。我们最终要做的是将这些敏感字符串作为加密字符串存储在 web.config 中。我认为对于您的场景,您可能会考虑执行类似的操作(在 web.config 中存储为加密字符串),但通过使用仅 Intranet 的 Web 服务进行包装并仅授予对一个域帐户的访问权限来将其集中化。这可确保除一个域帐户之外的任何人都无法调用 Web 服务来获取凭证或其他 PayPal 特定对象。

We did a PayPal implementation a while ago. What we ended up doing is storing these sensitive strings as encrypted strings in web.config. I think for your scenario you might consider doing something similar (storing as encrypted strings in web.config), but centralizing it by wrapping it with an intranet only web service and only giving access to one domain account. This ensures no one except the one domain account can call the webservice to get the credential or other PayPal specific objects.

浅紫色的梦幻 2024-08-26 15:02:48

如果字符串在编译时确定并且永不更改,请使用资源文件。

如果他们需要持久存储,您还可以使用系统注册表 - 我自己也在涉足这一点,还使用资源文件来减少关键的拼写错误:

// Get key
RegistryKey appKey = Registry.CurrentUser.CreateSubKey(Resources.keyAppPath);

// Read from key
string _configStr = (string)appKey.GetValue(Resources.keyConfigStr, string.Empty);

// Write to key
appKey.SetValue(Resources.keyConfigStr, _configStr);

Resources.keyAppPath 就像 “Software\[Company ]\[App]"

Resources.keyConfigStr 是密钥的名称。

正如其他人提到的,如果特定数据存在安全问题,请添加一层加密!

If the strings are determined at compile time and never change, use a resources file.

If they need persistent storage, you can also use the system registry - I am dabbling in this myself, also using resource files to reduce critical typos:

// Get key
RegistryKey appKey = Registry.CurrentUser.CreateSubKey(Resources.keyAppPath);

// Read from key
string _configStr = (string)appKey.GetValue(Resources.keyConfigStr, string.Empty);

// Write to key
appKey.SetValue(Resources.keyConfigStr, _configStr);

Resources.keyAppPath is like "Software\[Company]\[App]"

Resources.keyConfigStr is the name of the key.

As others have mentioned, add a layer of encryption if security is an issue with the particular data!

Oo萌小芽oO 2024-08-26 15:02:48

您的配置将取决于您的整体架构。如果您的消费应用程序不需要了解有关设置的任何具体信息,那么最好创建一个类来负责检索这些设置并将它们作为显式属性输出。最好将它们放在 web.config 的某个版本中,因为这样您就可以修改它们,而无需重新编译和重新部署应用程序。您可能还需要考虑任何源代码控制或管理不同级别的配置(开发、测试、生产、预生产等)。

我采用了 web.config 方法,该方法根据访问它的服务器的级别或类型创建我自己的配置部分和连接字符串部分。然后,我构建了自己的“ConfigurationManager”类,该类以与内置 ConfigurationManager 几乎相同的方式访问它们(因此它的使用对其他开发人员来说是透明的)。然后我的 web.config 中可以有任何设置,并且该类本身可以在整个企业中以与 ASP.Net 配置标准一致的方式相同地使用。任何需要设置的人都可以调用 myConfigurationManager.AppSettings(key) 并根据相关服务器的级别接收适当的设置,并且配置文件的源代码控制在服务器之间不必有所不同。

类似地,可以通过这种方式配置 app.config 以提供扩展配置支持。

Your configuration will depend on your overall architecture. If your consuming applications are expected to know nothing specific about the settings, then it might be best to create a class that is responsible for retrieving these settings and outputting them as explicit properties. It is probably always best to put them in some version of a web.config because this allows you to modify them without having to recompile and redeploy your application. You may also have considerations of any source control or managing different levels of configuration (development, test, production, preproduction, et al).

I employed a web.config method that creates my own config sections and connection string sections based on the level or type of server that is accessing it. I then constructed my own "ConfigurationManager" class that accesses them in a manner nearly identical to the built in ConfigurationManager (so its usage would be transparent to other developers). Then my web.config can have any settings in it and the class itself can be used identically across the enterprise in a manner consistent with ASP.Net configuration standards. Anyone needing a setting would call the myConfigurationManager.AppSettings(key) and receive the appropriate setting based on the level of the server in question, and the source control for the configuration file would not have to be different between servers.

Similarly an app.config can be configured in this way to provide extended configuration support.

—━☆沉默づ 2024-08-26 15:02:48

您可以创建一个简单的类来保存它们,将类 xmlSerialize 到您希望其他应用程序读回同一个类的任何位置。

You could just make a simple class that holds them, xmlSerialize the class to wherever you want to be read back into the same class by your other apps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文