.NET namespaces

Question

Moje doświadczenie jest przede wszystkim programistą Java, ale ostatnio robiłem trochę pracy w .NET. Więc próbowałem zrobić kilka prostych projektów w domu, aby lepiej pracować z .NET. Byłem w stanie przesłać wiele moich doświadczeń Java do pracy z .NET (konkretnie C#), ale jedyną rzeczą, która naprawdę mnie zakłopotała jest przestrzeń nazw.

Wiem, że przestrzenie nazw są podobne do pakietów Java, ale z tego co mogę powiedzieć, główna różnica polega na tym, że w pakietach Javy używają rzeczywistych folderów plików, aby pokazać separację, podczas gdy w .NET nie ma i wszystkie pliki znajdują się w jednym folderze i przestrzeń nazw jest po prostu zadeklarowana w każdej klasie.

Uważam, że to dziwne, ponieważ zawsze widziałem paczki jako sposób organizowania i grupowania powiązanych kodów, ułatwiając nawigację i zrozumienie. Ponieważ w .NET nie działa to w ten sposób, nadgodziny, projekt wydaje się bardziej przepełniony i nie jest tak łatwy w nawigacji.

Czy tu czegoś brakuje? Muszę być. Czy powinienem rozbijać rzeczy na osobne projekty w ramach rozwiązania? Czy istnieje lepszy sposób na utrzymanie klas i plików zorganizowanych w ramach projektu?

Edytuj: Jak zauważyła Blair, to samo pytanie zadano: here.

Answer 1

Nie mogę twierdzić, że jest to najlepsza praktyka, ale często widzę pliki zorganizowane w hierarchii katalogów, która odzwierciedla obszar nazw. Jeśli lepiej pasuje do twojego mentalnego modelu kodu, zrób to - nie mogę myśleć o żadnej szkodzie. Tylko dlatego, że model .NET nie wymusza relacji między przestrzeniami nazw, projektami i strukturą katalogów, nie oznacza, że ​​nie możesz mieć takich relacji, jeśli chcesz.

Byłbym trochę nieufny w rozbijaniu kodu na więcej projektów, niż jest to potrzebne, ponieważ może to spowolnić kompilację i dodać trochę narzut, gdy trzeba zarządzać wieloma złożeniami.

EDIT: Zauważ, że to pytanie jest niemal kopią should the folders in a solution match the namespace?

Answer 2

Możesz dodać foldery do sporządzania roztworu do każdej przestrzeni nazw. Chociaż nadal będzie kompilował się do jednego pliku wykonywalnego, organizuje pliki źródłowe i daje (moim zdaniem) pożądany efekt?

I zazwyczaj dodać folder dla każdej przestrzeni nazw w moim projekcie, a gniazdo je według tej samej hierarchii (MyApp.View.Dialogs na przykład)

Answer 3

roztwór A VS zwykle zawiera jeden lub więcej projektów. Te projekty mają domyślne przestrzenie nazw (zwykle przestrzeń nazw jest po prostu nazwą projektu). Normalnie, jeśli dodać folder, w ramach projektu, wszystkie zajęcia w nim będzie nazwany w następujący sposób:

DefaultNamespace.FolderName.ClassName

oczywiście, można zmienić domyślny obszar nazw projektu, a klasy powinny być nazwane w dowolny sposób.

Jeśli chodzi o czas/sposób rozbijania elementów na projekty, jest to kwestia doświadczenia i/lub preferencji. Jednak należy bezwzględnie dzielić rzeczy na projekty w ramach rozwiązania, aby utrzymać swój projekt w porządku. Jeśli zarządzanie zbyt wieloma złożeniami staje się uciążliwe (jak sugerowała Blair), zawsze możesz złożyć swoje złożenia w jeden zespół.To, co najlepsze w ILMerge, to fakt, że nawet jeśli skończysz z jednym zestawem, wszystkie twoje klasy zachowują swoje oryginalne, w pełni kwalifikowane nazwy.

Należy również pamiętać, że rozwiązanie VS nie ma wpływu na kod - tj. nie budują się. Rozwiązania VS są jedynie sposobem grupowania projektów; to projekty, które są budowane i przekształcane w biblioteki DLL.

Wreszcie, VS pozwala dodawać "wirtualne" foldery w dowolnym miejscu rozwiązania. Te foldery nie są mapowane do folderu w systemie plików i są używane tylko jako środek pomocny w organizacji projektów i innych artefaktów w ramach rozwiązania.

Answer 4

Tak, w przestrzeni nazw .NET nie zależy od systemu plików ani od niczego innego. To wielka zaleta w mojej opinii. Na przykład możesz podzielić swój kod na różne zespoły, co pozwala na elastyczną dystrybucję.

Podczas pracy w Visual Studio, IDE dąży do wprowadzenia nowej przestrzeni nazw po dodaniu nowego folderu do drzewa projektu.

Oto przydatny związek z MSDN:

Namespace Naming Guidelines

Ogólna zasada nazewnictwa nazw jest użycie nazwy firmy następnie nazwa technologii i ewentualnie funkcji i projektowania jako następuje.
CompanyName.TechnologyName [.Feature] [. Projekt]

Oczywiście można używać nazw w sposób, można znaleźć bardziej odpowiednie. Jeśli jednak zamierzasz udostępniać swój kod, zaleciłbym spełnienie akceptowanych standardów.

EDIT:

Gorąco polecam do każdego dewelopera .net aby uzyskać kopię Framework design guidelines Ta książka pomoże Ci zrozumieć jak i dlaczego NET jest przeznaczony.

Answer 5

Przestrzenie nazw są czysto semantyczne. Chociaż zwykle odzwierciedlają strukturę folderów, przynajmniej przy użyciu Visual Studio IDE, nie muszą tego robić.

Możesz mieć tę samą przestrzeń nazw, do której się odwołujesz w wielu bibliotekach, brzydką, ale prawdziwą.

Answer 6

Rzeczywiście, środowisko .Net pozwala rzucić kod na IDE/system plików, jak spaghetti na ścianie.

To jednak nie oznacza, że ​​takie podejście jest rozsądne. Generalnie dobrze jest trzymać się wzmiankowanej wcześniej metody project.foldername.Class. Dobrym pomysłem jest także zachowanie wszystkich klas z jednej przestrzeni nazw w tej samej klasie.

W Javie można robić takie paskudne rzeczy, jak również uzyskać wszystkie "elastyczność", które chcesz, ale narzędzia mają tendencję do silnego zniechęcenia go. Szczerze mówiąc, jedną z najbardziej mylących rzeczy dla mnie, gdy byłem wprowadzany do świata .Net, było to, jak niechlujne/niekonsekwentne może być to, dzięki relatywnie złym wskazówkom. Łatwo jest jednak uporządkować sprawy przy odrobinie myśli.:)

Answer 7

Zawsze uważałem organizację plików źródłowych i przypisywanie identyfikatorów do klas i obiektów za dwa odrębne problemy. Mam tendencję do utrzymywania powiązanych klas w grupach, ale nie każda grupa powinna być przestrzenią nazw. Przestrzenie nazw istnieją (mniej więcej) w celu rozwiązania problemu konfliktów nazw - w językach z płaskimi przestrzeniami nazw, takich jak C, nie można przejść dwóch stóp bez potknięcia się o identyfikatory takie jak mycompany_getcurrentdate lub MYCGetCurrentDate, ponieważ ryzyko konfliktu z inną funkcją w Biblioteka innych firm (lub systemu) jest o wiele mniejsza. Jeśli utworzyłeś pakiet lub przestrzeń nazw dla każdej separacji logicznej, otrzymasz nazwy klas (przykład Java), takie jak java.lang.primitivewrapper.numeric.Integer, co jest prawie przesadą.

Answer 8

Przestrzenie nazw są logicznym grupowaniem, a projekty są fizycznymi grupami.

Dlaczego jest to ważne? Pomyśl o .NET 2.0, 3.0 i 3.5. .NET 3.0 to w zasadzie .NET 2.0 z dodatkowymi złoŜeniami, a 3.5 dodaje jeszcze kilka złoŜeń. Na przykład .NET 3.5 dodaje kontrolkę DataPager, która jest kontrolą sieciową i powinna być zgrupowana w System.Web.UI.WebControls. Jeśli przestrzenie nazw i lokalizacje fizyczne są identyczne, nie może tak być, ponieważ znajdują się w innym zestawie.

Zatem posiadanie przestrzeni nazw jako niezależnych elementów logicznych oznacza, że ​​możesz mieć członków kilku różnych zespołów, które są logicznie zgrupowane razem, ponieważ mają być używane w połączeniu ze sobą.

(Również, nie ma nic złego w układy fizyczne i logiczne dość podobny.)

Answer 9

różnicą jest to, że .net nazw mają nic wiele wspólnego z pakietów Java.

Przestrzenie nazw .net są przeznaczone wyłącznie do zarządzania zakresem deklaratywnym i nie mają nic wspólnego z plikami, projektami lub ich lokalizacjami.

To bardzo proste, wszystko, co zadeklarowane w konkretnej przestrzeni nazw jest dostępne, gdy użytkownik poda "używanie" do tej przestrzeni nazw.

bardzo łatwe.

wybór nazwy i czy lub nie/ile "." seperators, których używasz, zależy wyłącznie od Ciebie.

VS domyślnie dodaje domeny .foldernames do twoich przestrzeni nazw, aby spróbować i być pomocnym.

ten artykuł wyjaśnia nazw całkiem dobrze: http://www.blackwasp.co.uk/Namespaces.aspx

Posiada również przykład konwencji nazewnictwa pod koniec, chociaż imię i nazwisko konwencja jest rozmowa! ;)

powiedział, że większość miejsc, w których pracowałem i ludzie, z którymi pracowałem zaczynają się od nazwy firmy, która jest sensowna, ponieważ sprawia, że ​​nazwy typowe dla tej firmy są odrębne, (oddzielne od innych, biblioteki, dostawcy, opensource projcts itp.)