Odziedziczyłem bazę kodu, która nie była dobrze przemyślana i mam problemy z okrężnymi odniesieniami. Mój zespół nie ma obecnie czasu ani zasobów na zrobienie ogromnego refaktora, więc zastanawiałem się, czy był jakiś przełącznik, który mógłbym przerzucić, mówiąc "buduj te dwa pliki dome atomowo".Czy są jakieś luki w rozwiązywaniu kolistych problemów referencyjnych?
Uproszczony przykład:
DLL D0:
class A1 -> References B1
class B1 -> References A1
Klasa A1 i B1 mają odniesienia do siebie, i jak są one w tym samym DLL, to jest w porządku - ale nie mają wiele wspólnego, więc chcesz podzielić je na osobne biblioteki dll.
Jednak po to niemożliwe z powodu okrągłego problemu odniesienia:
DLL D1: class A1 -> References D2.B1
DLL D2: class B1 -> References D1.A1
Chcę móc powiedzieć MSBuild zbudować (D1 + D2), jak gdyby cały kod były w jednym dll . Czy jest coś, co mogę tutaj zrobić, czy mogę postępować zgodnie z SOP i "włamać się do niego?"
Oświadczenie: Rozumiem, że to oznacza, że mam znacznie większy problem z moim modelem (najbardziej jaskrawe jest niewłaściwe użycie interfejsów), ale w małej firmie rzeczywiste scenariusze dyktują, że pochylam się do tyłu, aby naprawić błędy produkcyjne kosztem najlepszych praktyk.
Co jest zaletą dzielenia ich na osobne pliki fizyczne? Możesz mieć je w oddzielnych projektach i użyć MSBuilda do zbudowania pojedynczego modułu .netModule, który można następnie skompilować do pliku wykonywalnego ... ale idąc w drugą stronę ... nie tyle bez refaktoryzacji interfejsów i wtrysku zależności. – cfeduke
To brzmi jak hacki, które prowadzą do twojego problemu okrężnych odniesień i nie będą częścią prawdziwego rozwiązania. –