Kiedy klasa lub moduł powinien znajdować się w osobnym zestawie / bibliotece DLL?

Czy istnieją jakieś wytyczne dotyczące decydowania, kiedy klasa powinna znajdować się we własnym zestawie / bibliotece DLL? Często widzę dwie szkoły myślenia:

1) Każda „grupa” klas należy do własnej biblioteki DLL, np. Repozytoria, usługi, DTO, infrastruktura itp.

2) Wszystko powinno znajdować się w jednej bibliotece DLL, ale oddzielone przez przestrzenie nazw / foldery, np. Mieć bibliotekę DLL „Core” z dodatkowymi przestrzeniami nazw, np. Core.Repositories, Core.Services, Core.DTO itp.

W pracy zbieramy wszystko w jednym Zgromadzeniu o nazwie „Biznes”. Istnieje kilka folderów, ale nie ma prawdziwej separacji - obiekty biznesowe (z logiką, z których niektóre nie powinny nawet być klasami) są beztrosko umieszczane w folderze „BusinessObjects”. Rzeczy używane w więcej niż jednej klasie znajdują się w folderze „Core”. Narzędzia znajdują się w folderze „Narzędzia”, infrastruktura dostępu do danych to folder „Dane” - masz pomysł.

W przypadku nowego modułu, nad którym pracuję, chcę / muszę mieć oddzielną warstwę dostępu do danych (pomyśl podstawową implementację repozytorium), ale nie chcę po prostu wrzucać jej do folderu „BusinessObjects” z innymi 160 (!) zajęcia tam. Jednocześnie martwię się o utworzenie nowej biblioteki klas, ponieważ wszyscy są przyzwyczajeni do upychania klasy w jednej bibliotece; folder / przestrzeń nazw może jednak działać.

Uważam, że lepiej jest mieć więcej projektów (tj. Zespołów) z klasami podzielonymi według kategorii w każdym projekcie niż jeden projekt ze wszystkimi tymi klasami w osobnych przestrzeniach nazw. Powinieneś dążyć do tego, aby twoje projekty były wielokrotnego użytku i reprezentowały różne warstwy w aplikacji. Następnie możesz ponownie wykorzystać te projekty w przyszłych aplikacjach bez konieczności dołączania całej masy niepotrzebnych klas.

Na przykład, w oparciu o to, o czym wspomniałeś, zdecydowanie miałbym następujące projekty:

• Rdzeń
• Dane
• Domena (lub BusinessObjects)
• Usługi
• Narzędzia (lub pomocnicy)

„Wujek Bob” Martin z Clean Code, sława SOLID Principles przedstawiła tutaj trzy zasady :

• Zasada równoważności ponownego użycia wydania: Granulatem ponownego użycia jest granulat wydania.
• Wspólna zasada zamknięcia: Klasy, które zmieniają się razem, są pakowane razem.
• Wspólna zasada ponownego użycia: Klasy używane razem są pakowane razem.

Ogólna zasada jest taka, że ​​liczba projektów w swoim rozwiązaniu powinna być jak najniższa. Podziel je tylko wtedy, gdy musisz to zrobić, aby zaimplementować jedną lub więcej konkretnych historii użytkowników lub jeśli posiadanie jednego zestawu powoduje mierzalne problemy z wydajnością (zazwyczaj gdy osiągną rozmiar kilku megabajtów).

Niektóre inne zasady przewodnie, z którymi pracuję:

• Czy uważasz, że ponownie użyjesz tego kodu w innych projektach? W przypadku jednej grupy powiązanych aplikacji internetowych mieliśmy jeden moduł związany z kontem użytkownika, z którego korzystały wszystkie aplikacje, ponieważ wszystkie one używały tego samego modelu dla kont użytkowników i loginów. Zrobiłem podobne rzeczy z bibliotekami geometrii i matematyki i ponownie użyłem ich w wielu aplikacjach, po prostu włączając DLL.

• Czy chcesz mieć możliwość modyfikowania / wdrażania tego kodu bez ponownego wdrażania / ponownej kompilacji całego projektu? Czasami przydało się po prostu przebudowanie modułu, wdrożenie i ponowne uruchomienie aplikacji internetowej.

Wygląda na to, że w Twoim przypadku podstawowe i ogólne Repozytorium może być ponownie przydatne w przyszłości, warto, jeśli to możliwe, podzielić je na nową bibliotekę DLL.