konwencje nazewnictwa zespołu

Question

Zakładając, że masz przestrzeń nazw przydatną dla więcej niż jednego projektu w twojej firmie, w formacie "MyCompany.Core", czy masz zestaw nazwany dokładnie tak samo lub po prostu "Core". Dlaczego lub dlaczego nie?

Answer 1

Skorzystaj ze standardowych konwencji nazewnictwa .NET, nazwy zespołów to covered here. Będę zapisać (krótka) czytaj:

Czy wybrać imiona dla swoich DLL montażowych które sugerują duże kawałki funkcjonalności takich jak System.Data. Nazwy zespołów i bibliotek DLL nie muszą odpowiadać odpowiadać nazwom przestrzeni nazw, ale jest to uzasadnione, aby podążać za nazwą przestrzeni nazw przy nadawaniu zestawów.

Rozważmy DLL nazewnictwa według następującego wzoru:
<Company>.<Component>.dll
przypadku <Component> zawiera jeden lub więcej klauzul punktowe rozdzielono.

Na przykład plik Contoso.WebControls.dll.

Answer 2

Nazwa zestawu byłaby taka sama jak główna przestrzeń nazw. Ułatwia to ustalenie, który kod jest zbiorem i zapobiega kolizjom z innymi projektami (z innych firm), które mogą również używać niejednoznacznej nazwy "Core.dll".

Answer 3

Uważam, że najlepiej (opinia tutaj!) Nazwać złożenie po głównej przestrzeni nazw, którą zawiera, w twoim przypadku MyCompany.Core.dll. Nigdy nie wiadomo, czy plik ten znajdzie się poza firmą, a śledzenie go jest po prostu łatwiejsze.

Wyobraź sobie, że Microsoft o nazwie System.Core tylko Core.dll(System.Core), potem trzeba było Core.dll(MyCompany.Core) .... sobie wyobrazić, jak to robi owłosione szybko.

Answer 4

Preferuję MyCompany.ApplicationName.Core.DLL, to eliminuje szanse konfliktu, jeśli istnieją dwie lub więcej aplikacji z MyCompany.

Answer 5

jeśli rozwija się w środowisku przedsiębiorstwa, konwencja ta może być przydatna...

Przestrzenie nazw postępować zgodnie z [DomainEntityName] [AssemblyName] [Cel] [RelatedPurpose] Format gdzie DomainEntityName to nazwa funkcji biznesowych korzeń i nazwa AssemblyName jest funkcjonalnie wspierającym wymagania biznesowe.