Jak zorganizować F # źródło dużego projektu (>300 zajęć) w Visual Studio?
W C# można umieszczać pliki w folderach odpowiadających ich przestrzeniom nazw i przeglądać je w Eksploratorze rozwiązań.
W F # wydaje mi się, że muszę umieścić wszystko w zwykłej, specjalnie uporządkowanej liście do kompilacji. Kiedy dojdę do skali ~300 klas robi się to trochę zagmatwane i zdezorganizowane i zaczynam zazdrościć C# i myślę, że prawdopodobnie jest to cena za wnioskowanie typu.
Czy istnieją lepsze opcje niż dzielenie na kilka zespołów?
Sądząc po źródle kompilatora F # to trasa, którą obrali, ale mam dość duży system połączonych ze sobą komponentów (Controller - ViewModel - View, > 300 klas) chcę być w jednym zestawie z powodu kolistych zależności nawet na poziomie interfejsów.
Czy mam zapomnieć o jednym pliku - jednej klasie i stworzyć jakieś ogromne pliki? (np. w kompilatorze F # masz kilka plikĂłw ĹşrĂłdĹ 'owych w zakresie od 100KB do 300kb, a niektĂłre automatycznie wygenerowane okoĹ' o 1Mb!)
Co to jest twoje doświadczenie z dużymi projektami F#?
2 answers
Wspominasz o "kolistych zależnościach", dla jasności, F# nigdy nie pozwoli Ci rozłożyć kolistych zależności między plikami. Jeśli type Foo odnosi się do type Bar, A type Bar odnosi się do type Foo, to Foo i Bar muszą być zdefiniowane w tym samym pliku w tej samej grupie type ... and ... W F#.
Problem tutaj jest jednym z organizacji i nawigacji, który jest głównie o oprzyrządowanie. Explorer VS solution wyświetla listę plików; foldery umożliwiają "zwinięcie" grup plików, które mogą Ułatw organizowanie myśli lub poruszanie się na "wielkich odległościach" wielu plików. Jednak do nawigacji są różne inne narzędzia (przejdź do definicji, wyszukaj tekst w bieżącym projekcie, ...), aby umożliwić przejście do np. określonej definicji klasy. (Mam nadzieję, że narzędzia te będą nadal ulepszane w szczególności dla F#, jak również ogólnie dla VS, w przyszłych wydaniach.)
W każdym razie mocno wierzę ,że " dość duży system połączonych ze sobą komponentów (Controller-ViewModel-View, > 300 klas) " jest zapachem kodu. Jeśli nie możesz rozplątać ich tak, aby miały archetekuralne warstwy, które nie zależą od innych części (a więc mogą być zdefiniowane jako "pierwsze" w poprzednim pliku w F#), to masz większe problemy niż tylko "jak zorganizować swój kod F#". Mój opiniotwórczy pogląd jest chyba najlepiej wyrażony tutaj.
EDIT (2018): tymczasem narzędzia poprawiły, między innymi, go-to-definition, find-all-references, globalna zmiana nazw identyfikatorów, obsługa folderów, reorganizacja plików itp. zostały dodane w ciągu ostatnich kilku lat. Dla rozwiązań, które wymagają wzajemnych odniesień między klasami, namespace rec i module rec zostały wprowadzone w celu ograniczenia potrzeby type ... and ....
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-03-28 19:12:02
Możesz też mieć foldery w F# projects. To trochę uciążliwe, ale działa.
Myślę, że umieszczenie wielu klas w jednym pliku jest całkowicie w porządku i idiomatyczne W F# Jeśli klasy są ze sobą ściśle powiązane.
Nie pracowałem jeszcze Przy naprawdę dużych projektach F#, ale interesuje mnie również doświadczenie innych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-23 19:05:12