Уровень обслуживания противВспомогательные объекты?

Question

Я бы хотел узнать ваше мнение по конкретному делу, пожалуйста.Речь идет об Уровне обслуживания по сравнениюВспомогательные объекты - и я не ищу идеалистические шаблоны, а просто хорошее понимание того, что думают по этому поводу мои дорогие коллеги-программисты:

В моем текущем приложении у меня есть полная модель домена (Linq to Sql, чрезвычайно легкие репозитории, а затем использование методов расширения в IQueryable<> для фильтрации / сортировки / упорядочивания на основе бизнес-требований), а затем уровень обслуживания, который содержит сервисы, основанные на группировании обязанностей, такие как IRegistrationService (регистрация пользователей, проверка доступности имен для входа и т.д.)

Теперь оговорка.У меня также есть несколько "вспомогательных" классов, которые выполняют такие вещи, как шифрование, и я также поместил в этот каталог другие не сгруппируемые элементы (например, пользовательские перечисления и т.д.)

Теперь мне нужно создать новый класс, который будет обрабатывать генерацию пользовательских ссылок для моего приложения, которое едва ли больше String.Форматирование с использованием различных объектов с учетом их свойств.Внутренняя работа не имеет значения.Однако сейчас мне сложно создать какой-то "LinkService", который будет это делать - я чувствую, что в итоге у меня будет 100 сервисов (и их интерфейсы + реализация), когда я закончу.

В то же время я не чувствую, что хочу создавать какое-то свободное сочетание классов и других материалов в моем пространстве имен / каталоге "Помощников" (напримерLinkManager).

Что же делать?Куда вы, ребята, помещаете материалы, которые все еще находятся на уровне бизнес-уровня, но в то же время как вы ограничиваете количество элементов на вашем бизнес-уровне / уровне обслуживания?Куда вы засовываете все эти маленькие вспомогательные классы, такие как промежуточные объекты, которые упрощают доступ к сеансу и управляют им (я предполагаю, что вы хотите, чтобы это было строго типизировано - по крайней мере, я хочу)?

Дай мне знать, что ты думаешь?Спасибо!

Answer 1

Для меня ключевым моментом является использование правильного инструмента для выполнения этой работы.Если вам нужно какое-то средство для генерации ссылок, которое в основном представляет собой сопоставление свойств объекта с форматированными строками, то напишите средство для этого.Это не обязательно должен быть сервис ... напротив, иметь полноценный сервис для чего-то подобного, вероятно, излишне.Однако я бы не стал просто относить это к вашим общим "помощникам".Похоже, что это нечто, имеющее определенную цель и замысел, за которыми стоит определенный тип поведения.Таким образом, поместите его в место, подходящее для такого поведения ... даже если это новый проект.

Я стараюсь, чтобы в моих приложениях не было огромного куска "общего" кода.Все имеет свою цель и реализует определенное поведение.Иногда эта цель и поведение требуют многократного использования, но я все равно стараюсь логически организовать эти многократно используемые элементы моего домена.На высоком уровне я вижу, что большинство моих приложений разделены на следующие:

1. Клиент
2. API/Сервис
3. Домен
4. Доступ к данным (необязательно)
5. Структура

Большая часть такого рода повторно используемой функциональности находится в своего рода промежуточной области между Фреймворком и Доменом.Часть этого может существовать в виде некоторых базовых классов и / или интерфейсов и поддерживающих типов во Фреймворке, а другая половина, конкретные реализации, находятся в моем Домене.Иногда это кажется странным, но организация его таким образом помогает мне поддерживать мой домен как можно более чистым (предназначенным для решения бизнес-задач), в то же время позволяя мне абстрагировать общие и повторно используемые концепции в "рамочные" типы более низкого уровня.