Что включить в служебную библиотеку - PullRequest
Новая
       45

Что включить в служебную библиотеку

3 голосов
/ 02 января 2009

Имея все больше и больше проектов, я обнаружил, что часто повторяю много общих задач от проекта к проекту, от клиента к клиенту. Поэтому я начал собирать «служебную» библиотеку, набор этих общих элементов, которые часто повторяются от проекта к проекту.

Пока у меня есть утилиты для изменения размера изображений, экспорта сеток данных в Excel, отправки электронных писем и замены токенизированных сообщений.

Если бы вы создавали / использовали библиотеку служебных классов .NET, какие типы процессов вы бы сочли полезными? Какие пространства имен / группы вы бы представили?

Обновление

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

Ответы [ 5 ]

5 голосов
/ 02 января 2009
  1. Я бы не стал писать библиотеку под названием «Обычная», «Утилиты», «Разное» или ... Вы поняли идею. Вместо этого у меня был бы каталог с именем «Lib», и каждая область функциональности находилась бы в отдельной библиотеке. Например, у меня может быть Lib / Trace, Lib / UI, Lib / Net, Lib / Web для проекта C ++. Для C # мне нужны Lib / Acme.Trace, Lib / Acme.Windows.Forms, Lib / Acme.Net и т. Д. (При условии, что ваше пространство имен / компания верхнего уровня называется «Acme»).
  2. YAGNI. Не пишите код, который вам может понадобиться.
  3. Не бросайте вещи в общую библиотеку, пока вы не используете их в двух или более проектах.
1 голос
/ 02 января 2009

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

Независимо от того, если у него нет домена, вы, вероятно, не понимаете его полностью, что означает, что вам следует сначала оценить то, что вы делаете и пытаться выполнить.

Также помните, что то, что полезно в одном или двух проектах, может оказаться полезным только в одном или двух проектах. Добавление большего количества классов, чем необходимо, только вызывает проблемы с техническим обслуживанием в будущем.

1 голос
/ 02 января 2009

В моей библиотеке классов есть много вещей, которыми я делюсь между проектами:

  • Контейнер IoC и структура внедрения зависимостей
  • Полная структура контроллера / наблюдателя, позволяющая отделить код пользовательского интерфейса от кода обратной логики
  • Разумный, независимый от базы данных набор классов для выполнения SQL, учитывает некоторые синтаксические различия, в основном имена функций
  • Множество других вспомогательных классов и служебных методов для работы с данными
  • Некоторые стандартизированные классы внутренней памяти, такие как Tuple<..> и т. Д.
  • Некоторые пользовательские коллекции, такие как Set<T>, Heap<T>, а также множество полезных методов для работы с различными типами коллекций

Библиотека классов добавляется, когда мне нужно больше вещей.

1 голос
/ 02 января 2009

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

Если бы внутри библиотеки она была разбита на описательные пространства имен, то я бы сказал, что это лучше (например, изменение размера изображений будет в некотором пространстве имен .Drawing или в файле .Drawing.dll).

0 голосов
/ 02 января 2009

Хотя я и сам начинающий разработчик, я обнаружил, что функции RegEx и фильтры SQL весьма полезны. У меня также есть функция репликации слиянием для MSSQL, которая мне пока очень удобна.

...