Как структурировать проект утилиты / компаньона в многопроектном решении - PullRequest
0 голосов
/ 04 августа 2010

Допустим, у меня есть решение Visual Studio с веб-проектом, BLL-проектом и DAL-проектом.Я пытаюсь следовать шаблону хранилища, сохраняя свой код SQL в DAL с интерфейсом, на который ссылается BLL.

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

Вот несколько идей, которые у меня были в отношении структурирования проекта Common ...

  1. Объединение SQL с логикой вданный класс
  2. Создание многоуровневого решения в рамках общего проекта
  3. Отказ от общего проекта и добавление служебных функций с помощью BLL / DAL

Является ли одна из этих идей лучше/ хуже другого?У кого-нибудь есть лучшее решение?

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

1 Ответ

0 голосов
/ 04 августа 2010

Вместо создания проекта утилит, который будет использоваться , вы задумывались о создании чего-то, что может предоставить услугу? Возможно, вы захотите взглянуть на Аспектно-ориентированное программирование . Красные флажки поднялись, когда я увидел, как вы перечислили примеры обработки ошибок, ведения журналов и т. Д. Эти крики AOP.

Но если вы хотите придерживаться своего макета.

Я думаю, что я бы пошел со 2, предполагая, что это означает, что реструктуризация проекта коммунальных услуг будет более сплоченной.

Я не понимаю (уточните, и я отредактирую свой пост)

  1. Пакет SQL с логикой в ​​данном классе

Что касается:

Отменить общий проект и добавить служебные функции с помощью BLL / DAL

Я был бы против этого. Если эта логика действительно будет повторяться, нет необходимости возвращать ее в свои проекты. Это приведет к дублированию кода и увеличению обслуживания.

Примечание:

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

...