Obejrzałem wczoraj taką oto prezentację
tl;dw:
Gościu mówi przede wszystkim o tym, że pakiety (w javie) powinno się pisać tak, że wszystkie klasy wchodzące w skład pakietu powinny być widoczne tylko w jego obrębie. Poza jedną klasą (fasadą), która powinna stanowić api do wchodzenia w interakcję z tym modułem.
I generalnie wydaje mi się to sensowne bo znacznie obniża zależności pomiędzy poszczególnymi częściami aplikacji i sprawia, że łatwo znaleźć wszystko "z czego możemy skorzystać" w ramach danego pakietu.
No, ale właśnie. Ja uczę się pisać w C#, wydaje mi się jakiś taki przyjemniejszy od javy. W C# czymś co zdaje się być najbardziej zbliżonym do pakietów z javy są przestrzenie nazw, ale nie istnieje modyfikator dostępu ograniczający widoczność klasy do namespace'u.
Zostaje modyfikator internal. I stąd moje pytanie. Czy ma sens dzielenie solucji na osobne projekty wg. funkcjonalności? Tylko proszę nie pisać, że przecież mogę zrobić wszystko :D Nie pytam czy da się to zrobić, tylko czy ma to wg. Was sens, czy spotkaliście się z takim podziałem w C# albo czy istnieją jakieś inne "standardy" projektowania aplikacji w tej technologii?
Dodam tylko, że do tej pory wszystkie projekty "tutorialowe" z jakimi się zetknąłem były na poziomie projektów podzielone mniej więcej tak:
*-App.Core
*-App.Data
*-App.Infrastructure
*-App.Web
itd.