我在一家公司工作，我们有很多小型ASP.Net/C#应用程序。我一直在努力通过为常见功能（如Active Directory查找，FTP等）创建共享库来集中尽可能多的功能。
我正在尝试创建一个能够执行SMTP交互的电子邮件DLL。我想使这个基于配置，所以它是动态的，但我不必在每个web.config中放置SMTP服务器名称，端口等。
是否有最佳做法是建立一个基于配置的共享库，但不依赖于每个应用程序的web.config？我也不想把它绑在machine.config上，所以它是可移植的。
我希望每个应用都能够调用方法而无需传递参数：
EmailLib.SendEmail("a@b.com", "This is the subject",....);
感谢。
答案 0 :(得分：2)
我认为最佳做法是将配置信息存储在每个应用程序的web.config（或应用程序配置）文件中。
如果你真的不想这样做，你可能会“自己动手”。特别是，我会写一些看起来不像普通.NET配置文件的东西，所以未来的维护者不会对你正在做的事情感到困惑。
DLL的配置文件总是很尴尬。一旦您希望不同的应用程序为DLL的配置文件设置不同的设置，您就会遇到重要的部署，维护，源代码控制和单元测试问题（这是设置首先在配置文件中设置的主要原因之一） ，对吧？）。
通常，配置设置属于应用程序，而不属于组件。
答案 1 :(得分：0)
您必须将配置存储在某处。 。 。数据库可能是一个选项。类似于特定于应用程序的配置表。您可以使用反射来确定调用应用程序的名称，并使用它来查找数据库表中的行。但是，您如何配置数据库连接？鸡？蛋？第一λ
GW下面有一个好主意，但在某些时候你会有“硬代码”对你需要的数据的一些引用（配置文件，数据库连接）即使有了web服务，你仍然会假设每个应用程序都会这样做类似于发送来自不同域的电子邮件，必须告诉webservice从哪个域发送。
答案 2 :(得分：0)
您可以将您的电子邮件功能放在Web服务或WCF服务中。这会将配置设置保存在一个地方。
答案 3 :(得分：0)
我创建了一个“设置”库，它本质上只是一个读取/写入db表的namevaluepair库。它足够灵活，可以容纳大量数据类型，并且可以重复使用。您可以在每个其他库中轻松实现此类库。调用某种功能，如：
AgileSetting.SetSetting("EmailSubject", "All your base are belong to us");
string emailSubject = AgileSetting.GetSetting("EmailSubject");
您还可以将其带到另一个级别，并创建某种设置分组以帮助组织它们。
答案 4 :(得分：0)
我认为从长远来看，你不会想要使用像这样的一整套硬编码的东西。您的所有应用程序可能都有不同的电子邮件地址以供支持，并且可能希望使用不同的主题（以便对问题进行正确描述，而不是使用foo-corp app的通用'错误'）。
但是对于一般问题，嗯，你可以有一个'.properties'文件，通用的NAnt构建将以某种方式适当地处理。
答案 5 :(得分：0)
我个人更喜欢创建从存储在IOC容器中的外部文件（例如xml，dsl）填充的配置类，然后将其注入到正在使用它的服务中。这里详细描述了这个过程configuration in conjunction with an IOC container
这样做的好处是我可以为每个服务器配置多个配置，只需将配置注入到我的单元测试的类中。此外，所有内容都是强类型的，因此我应该担心在应用程序启动后将int转换为字符串或任何内容。