C# Как организовать инструменты DLL?

Я хотел бы знать, что является лучшим способом организовать инструменты DLL.

Например, у меня может быть проект, который имеет все инструменты класса, которые были реализованы компанией. Например, класс для работы со строками, класс для работы с файлами... и так далее. Я имею в виду универсальный dll с инструментами, которые я могу использовать во многих проектах. Это будет общий myCompaty.Utils.dll, например.

Другой способ это иметь много dll, для каждого типа работы. Например, у меня может быть myCompany.Utils.Files, другие myCompany.Utils.Strings... и т. Д.

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

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

Поэтому я хотел бы знать, что является лучшей практикой, когда создается DLL.

Благодарю.

3 ответа

Решение

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

В моем магазине только один / два человека могут что-либо менять там. И эти ребята самые опытные и ценные коллеги.

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

Из вашего вопроса ясно, что вы не используете систему контроля версий. Попробуйте проверить что-то вроде Tortoise SVN - тогда у вас не будет проблем с несколькими людьми, работающими над одним и тем же программным обеспечением.

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

В основном это будет зависеть от количества классов, интерфейсов и делегатов, которыми будет владеть ваша библиотека.

Представьте себе, что у вас 3000 классов в вашем "Company.Shared.dll" и вы разрабатываете веб-приложение. 600 из 3000 классов предназначены для мобильной разработки. Какова вероятность их использования при разработке веб-приложений? Ноль

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

По этой причине у вас будет общая библиотека с именем Company.Shared.Web.dll и общая для всех сценариев разработки компания с именем Company.Shared.dll.

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

Другие вопросы по тегам