Общие библиотеки на основе конфигурации (DLL)

Question

Я работаю в компании, где у нас много небольших приложений ASP.Net/C#. Я прилагаю усилия для централизации как можно большей части функциональности путем создания общих библиотек для общих функций (таких как поиск в Active Directory, FTP и т. Д.).

Я пытаюсь создать почтовый dll, который будет выполнять SMTP-взаимодействия. Я хотел бы сделать это на основе конфигурации, чтобы он был динамичным, но мне не нужно указывать имя SMTP-сервера, порт и т. Д. В каждом файле web.config.

Есть ли лучший способ создать общую библиотеку, основанную на конфигурации, но не основанную на web.config каждого приложения? Я также предпочел бы не привязывать его к machine.config, чтобы он был переносимым.

Я хочу, чтобы каждое приложение могло вызывать методы без передачи параметров:

EmailLib.SendEmail("a@b.com", "This is the subject",....);

Спасибо.

Answer 1

Я бы сказал, что лучше всего хранить информацию о конфигурации в файле web.config (или конфигурации приложения) для каждого приложения.

Если вы действительно не хотите этого делать, скорее всего, вы находитесь на территории, где вы «катаетесь». В частности, я бы написал что-то, что не похоже на обычный конфигурационный файл .NET, чтобы будущие сопровождающие не запутались в том, что вы делаете.

Файлы конфигурации для библиотек DLL всегда неудобны. Вы сталкиваетесь со значительными проблемами развертывания, обслуживания, контроля версий и модульного тестирования, как только вы хотите, чтобы разные приложения имели разные настройки для конфигурационного файла DLL (что является одной из основных причин, по которым эти настройки в первую очередь находятся в конфигурационном файле). , верно?).

Обычно настройки конфигурации принадлежат приложению, а не компоненту (-ам).

Answer 2

Я предпочитаю создавать класс конфигурации, который заполняется из внешнего файла (например, xml, dsl), хранящегося в контейнере IOC, а затем внедряется в сервис, который его использует. Процесс хорошо описан здесь конфигурация в сочетании с контейнером IOC

Преимущество этого в том, что я могу иметь несколько конфигураций на сервер и просто вводить конфигурацию в класс для моих модульных тестов. Кроме того, все строго типизировано, поэтому мне нужно беспокоиться о преобразовании целых чисел в строку или что-нибудь еще после запуска приложения.

Answer 3

Я бы сказал, что в долгосрочной перспективе вы не захотите использовать целый набор жестко закодированных вещей, подобных этому. Все ваши приложения, вероятно, будут иметь разные адреса электронной почты для поддержки и, возможно, захотят использовать разные темы (чтобы иметь правильное описание проблемы, а не общую «ошибку с приложением foo-corp»).

Но что касается общей проблемы, у вас может быть файл .properties, который обобщенная сборка NAnt будет обрабатывать соответствующим образом.

Answer 4

Я создал библиотеку «Настройки», которая по сути была просто библиотекой namevaluepair, которая читает / записывает в таблицу БД. Он достаточно гибкий, чтобы вместить много типов данных, и его можно использовать повторно. Вы можете легко реализовать такую ​​библиотеку в каждой из ваших других библиотек. Вызовите какую-нибудь функцию, например:

AgileSetting.SetSetting("EmailSubject", "All your base are belong to us");
string emailSubject = AgileSetting.GetSetting("EmailSubject");

Вы также можете перевести его на другой уровень и создать некую группу настроек, чтобы упорядочить их.

Answer 5

Вы можете поместить свою электронную почту в веб-сервис или сервис WCF. Это сохранит настройки конфигурации в одном месте.

Answer 6

Вы должны где-то хранить конфигурацию. , , база данных может быть вариантом. Что-то вроде таблицы конфигурации приложения. Вы можете использовать отражение, чтобы определить имя вызывающего приложения, и использовать его для поиска строки в таблице базы данных. Но тогда как вы настраиваете соединение с базой данных? Курица? Яйцо? Во-первых

У GW есть хорошая идея ниже, но в какой-то момент у вас будет «жесткий код» с некоторой ссылкой на нужные вам данные (файл конфигурации, подключение к базе данных). Даже с веб-сервисом вы все равно будете предполагать, что каждое приложение будет что-то наподобие отправки писем с другого домена, нужно указать веб-службе, с какого домена отправлять.