Имена пространства имен и сборки для повторно используемого компонента

Question

У меня на руках немного головоломки.

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

У меня проблемы с определением подходящего пространства имен и имени сборки.

По сути, в настоящее время я использую JasonSummers.Validation в качестве примера для моей библиотеки валидации, поскольку у меня нет «компании» и конкретного проекта, к которому применяется код.

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

Я бы просто использовал «Проверка» в качестве пространства имен (в конце концов, StructureMap - это StructureMap, а не JeremyMiller.StructureMap), но это может вызвать путаницу у будущих разработчиков, поскольку «Проверка» используется в наборе «Систем» пространств имен, предоставляемых .net

Все комментарии с благодарностью.

Answer 1

Вы всегда можете использовать имя из биологии, например, Tribulus. или любой другой для вашего корневого пространства имен. Таким образом, ваш код входит, например, в Tribulus.Validation или Tribulus.Utilities и т. Д. Пространство имен Toplevel не обязательно должно быть функциональным именем. Это может быть просто подпись компании или просто уникальное интересное имя, как я уже упоминал.

Answer 2

Взгляните на Рекомендации Microsoft по именованию пространств имен

Я получил ответ от Конамиман на мой вопрос , который относится к вашему.

Answer 3

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

Можно использовать нейтральное имя, например Reusable, и объединить сборку утилиты с помощью команды ilmerge framework.