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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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