Struktura katalogów dla rozwiązania .NET

16

Niedawno mieliśmy wizytę kontrahenta, który zakwestionował naszą metodologię strukturyzacji projektów. Pamiętaj, że mam na myśli zwłaszcza strukturę katalogów. Zasugerował użycie wytycznych Microsoft. Myślałem, że będę w stanie znaleźć w Google „strukturę katalogów projektu .NET dla wytycznych Microsoft” i znaleźć coś pomocnego, ale okazało się, że tak nie jest. W tej chwili robimy coś takiego:

[Company.System.Feature]
  |-doc
     |Sandcastle project
  |-lib
     |Nuget packages
  |-src
    |-Project1 e.g. web
    |-Project2 e.g. business logic
    |-UnittestProject1
    |-Specs

Folder doc zawiera rozwiązanie Sandcastle, takie jak opisane tutaj: https://www.codeproject.com/Articles/15176/Sandcastle-Help-File-Builder (patrz: ścieżki bezwzględne i względne). Dlatego folder doc zawiera folder Pomocy, który zawiera wygenerowany plik pomocy. Folder lib zawiera wszystkie pakiety Nuget.

Czy istnieją jakieś wytyczne firmy Microsoft, które zalecają tworzenie struktury rozwiązania? Szukałem tutaj: /programming/789389/project-structure-for-c-sharp-development-effort/789554?noredirect=1#comment86756309_789554 między innymi miejscami. Większość artykułów i pytań, które przeczytałam, wydaje się być tworzona w latach 2007-2009. Wierzę, że Nuget został wprowadzony w 2010 roku. Czy istnieją jakieś wytyczne Microsoft? Czytałem o czymś zwanym Tree Surgeon, jednak wydaje się, że już nie istnieje: https://archive.codeplex.com/?p=treesurgeon .

Używam TFS; Tempomat i DDD mają znaczenie.

w0051977
źródło
4
Struktury katalogów są w dużej mierze kwestią gustu. Użyj struktury folderów, która najlepiej określa intencje twojego projektu / organizacji.
Robert Harvey
5
Również następnym razem, gdy ktoś powie, że powinieneś postępować zgodnie z „Wytycznymi Microsoft”, poproś tę osobę o podanie tych wskazówek lub wskazanie, gdzie możesz je znaleźć. W przeciwnym razie jest to bezużyteczna rada.
Robert Harvey
2
dziwne jest umieszczanie pakietów nuget w lib zamiast pakietów
Ewan
1
@Ewan, pakiety nuget już nawet nie należą packagesdo projektów dotnetcore i VS2017. Teraz mieszkają w objkatalogach projektów .
David Arno
2
pff! aktualizacja?!?!? wygląda na to, że może to popsuć
Ewan

Odpowiedzi:

21

W witrynie MSDN istnieje kilka bardzo starych oficjalnych wytycznych . Te są jednak nieaktualne. Jak mówi strona: „ Ta treść jest przestarzała i nie jest już utrzymywana. Jest udostępniana jako uprzejmość dla osób, które nadal korzystają z tych technologii. Zalecam więc unikanie tych wytycznych.

Podjęto próbę zdefiniowania wspólnej struktury rozwiązania za pośrednictwem Project Scaffold . Jest to jednak bardziej zorientowane na F # niż na C #. Jednak tak naprawdę nie wystartował i obecnie niewiele jest oznak rozwoju pomysłów.

Najbardziej aktywny i aktualny zestaw wytycznych jest utrzymywany przez Davida Fowlera, który jest programistą w firmie Microsoft w zespole ASP.NET. Z tych wytycznych korzysta wiele osób w firmie Microsoft, w tym zespoły Roslyn (kompilator C # i VB.Net). Dlatego możesz zrobić o wiele gorzej niż przyjąć takie podejście.

David Arno
źródło
Widziałem dwa pierwsze linki, ale nie trzeci. +1 za trzeci link. Czy umieściłbym cały projekt Sandcastle w folderze docs lub tylko pliki pomocy generowane przez projekt Sandcastle? Nie jestem pewien, dlaczego ta odpowiedź została odrzucona.
w0051977
1
Szczerze mówiąc, każda strona, która nie jest uwzględniona w nowym systemie dokumentacji Microsoft, jest opatrzona słowami „ta treść jest nieaktualna i nie jest już utrzymywana”. To nie znaczy, że nie ma tam żadnych użytecznych informacji.
Robert Harvey
Czy umieściłbyś specyfikacje? W folderze Tests lub w katalogu o nazwie Specs (w tym samym katalogu co folder src)? Myślę, że to naprawdę nie ma większego znaczenia.
w0051977
@RobertHarvey: Wystarczająco sprawiedliwe, ale odwołanie się do samej strony bez dalszych kopii zapasowych również nie jest powodem do zmiany struktury folderów projektu, jeśli została już utworzona inna.
Flater
Wytyczne Davida Fowlersa można zobaczyć w praktyce w większości projektów open source w GitHub, np. Enity Framework .
pfx