Wzorce architektoniczne

Cześć

Mam pytanie. Projektując wiesze systemy informatyczne skąd mam wiedzieć, że wybrałam odpowiednie rozwiązanie?
Skąd mogę wiedzieć jaka baza danych będzie lepsza? MySQL czy MSSQL?
Czy do tworzenia aplikacji przykładowo kółko i krzyżyk po sieci będzie nadawał się web servie?
Do napisania nawigacji WCF czy web service?

Oczywiście odpowiedz jest prosta - zależy do czego?
Ale skąd ja mam wiedzieć, które rozwiązanie do czego pasuje?
Znacie jakąś literaturę, która powie mi jak projektować systemy informatyczne i powie jaką architekturę stosować przy danym problemie?

Preferuje literaturę polską, z tego względu, że wystarczająco trudno już po polsku będzie mi to zrozumieć...
Najlepiej jeśli będzie to coś pod kontem .NET :)
Będę wdzięczna za pomoc :)

Takie pytanie na boku (proszę o odpowiedz w komentarzu a nie w poście, aby nie "brudzić w temacie".
Jak nazywa się informatyk w firmie, który decyduje jaką technologie wybrać, jakie rozwiązanie będzie najadekwatniejsze do problemu?

Jak nazywa się informatyk w firmie, który decyduje jaką technologie wybrać, jakie rozwiązanie będzie najadekwatniejsze do problemu?

Architekt oprogramowania, zwykle w porozumieniu z lead developerami.

Projektując wiesze systemy informatyczne skąd mam wiedzieć, że wybrałam odpowiednie rozwiązanie?

Architekci to zwykle ludzie którzy mają po 10+ lat doświadczenia w branży, z czego wiekszość jako programiści i znają różne technologie na wylot. Poza tym mają sporo doświadczenia w pracy z różnymi projektami i widzieli już różne rozwiązania i potencjalne problemy. Stąd też mogą wybrać technologie i podejścia najbardziej adekwatne.

Skąd mogę wiedzieć jaka baza danych będzie lepsza? MySQL czy MSSQL?

Po pierwsze z dokumentacji która opisuje do jakich zastosowań dana baza się nadaje. Po drugie z doświadczenia - jeśli pracowałaś w projektach z jedną i z drugą to wiesz jakie są ich mocne i słabe strony. Jeśli technologia jest "nowa" lub nie jest dobrze poznana przez zespół to robi się tzw. "tech spike" czyli pewnego rodzaju prototypowanie z użyciem danej technologii które ma ściśle określone ramy czasowe. Na koniec spika podejmuje się decyzję czy technologia się nadaje czy też nie.

Czy do tworzenia aplikacji przykładowo kółko i krzyżyk po sieci będzie nadawał się web servie?

Jak bardzo chcesz to możesz tak napisać, ale będzie to miało niewielki sens poza dydaktycznym. Serwis jak sama nazwa wskazuje to jest coś z czego korzysta wielu klientów. Web Serwis podający prognozę pogody albo notowania giełdowe ma sens. Web Serwis do komunikacji w kółko i krzyżyk średnio. No chyba że chcesz żeby potencjalnie wiele osób mogło napisać swoje własne "klienty" do tej gry w różnych technologiach. Wtedy może to mieć jakiś minimalny sens.

Do napisania nawigacji WCF czy web service?

jw.

Ale skąd ja mam wiedzieć, które rozwiązanie do czego pasuje?

Jak popracujesz 5-6 lat to będziesz wiedzieć, bo zobaczysz jak różne technologie sprawdzają się w różnych zastosowaniach. Jak spędzisz miesiąc rzeźbiąc w brązie, bo ktoś źle dobrał technologię do będziesz na przyszłość pamiętać, żeby tak nie zrobić ;)

Znacie jakąś literaturę, która powie mi jak projektować systemy informatyczne i powie jaką architekturę stosować przy danym problemie?

Gdyby to było takie proste to architekci nie dostawaliby pięciocyfrowych wypłat netto ;)
Ale możesz poczytać np. http://www.eaipatterns.com/toc.html przy czym bez doświadczenia w programowaniu to guzik ci to da.

Ogólnie jeśli myślisz ze możesz przeczytać dwie książki i zostać architektem bo "nie lubisz programować" to niestety ale tak się nie da.

Trochę źle mnie zrozumiałeś.

Wyżej podałam tylko przykłady a nie problemy z którymi muszę się uporać.

I nie planuje zostać kimś więcej niż programistką, ale często borykam się jaką architekturę wybrać (co z czym pożenić) przy rozpatrywaniu danego problemu, potem robię w duszy przekonana, że moja teoria jest super a w rzeczywistości...

Ktoś mi podpowiedział, że to nazywa się wzorce SOA i kupiłam tą książkę:
http://helion.pl/ksiazki/wzorce-soa-arnon-rotem-gal-oz,wzosoa.htm

Ale grubo się rozczarowałam, bo to nie to co chciałam...

Więc szukamy dalej? Ktoś poleci jakąś polską, książkową literaturę?

@Shalom strona, która podałeś jest ciekawa bo rozwiązuje część takich przypadków z jakie miałam na myśli, ale ja jestem ambitniejsza i potrzebuje więcej :)

Ogólnie jeśli myślisz ze możesz przeczytać dwie książki i zostać architektem bo "nie lubisz programować" to niestety ale tak się nie da.

Pewnie, że nie lubię programować!
I <3 programing!

marta1995 napisał(a):

Projektując wiesze systemy informatyczne skąd mam wiedzieć, że wybrałam odpowiednie rozwiązanie?

Dowiesz się po napisaniu. :)

Skąd mogę wiedzieć jaka baza danych będzie lepsza? MySQL czy MSSQL?

A jaki masz budżet, jakie potrzeby, ile danych chcesz przechowywać, i w jakim języku będzie napisana aplikacja korzystająca z tej bazy?

Czy do tworzenia aplikacji przykładowo kółko i krzyżyk po sieci będzie nadawał się web servie?

Zapewne nie, to zbyt prosty przypadek.

Web serwisy tworzy się, gdy chce się udostępnić jakąś funkcjonalność na zewnątrz, albo gdy tworzy się naprawdę duży system, w którym jest sens utworzenie oddzielnej warstwy ze względów wydajnościowych (podział aplikacji na wiele serwerów, część dla webserwisów, część dla serwerów www).

Znacie jakąś literaturę, która powie mi jak projektować systemy informatyczne i powie jaką architekturę stosować przy danym problemie?

Np. to: http://helion.pl/ksiazki/architektura-systemow-zarzadzania-przedsiebiorstwem-wzorce-projektowe-martin-fowler,szabko.htm

Ale to tylko opis różnych podejść. Nie istnieje książka, której potrzebujesz, bo nie da się takiej napisać. Zbyt wiele rzeczy zależy od kwestii specyficznych dla danego problemu, a technologie i podejścia zmieniają się tak szybko, że nie można ustalić jakichś zasad "raz na zawsze", bo za 5-10 lat są już nieaktualne.

Dziękuje Panowie, mam jeszcze jedno pytanie.
Jaka Waszym zdaniem jest najlepsza literatura uczenia się techniki programowania modułowego?
Mówię tutaj w koncepcji programowania już systemów informatycznych.
Co zrobić, aby stworzyć system, w którym się nie zakopie, gdzie będę mogła programować modułowo, przez co mój kod będzie bardzo uniwersalny i nastawiony na rozbudowanie?
Najlepiej właśnie by było poznać taką książkę kierującą pod platformę .NET
Widziałam, że książek na ten temat jest sporo, ale chce poznać Waszą opinie i w tym miejscu uwaga, że nie chciałabym książki jak pisać czysty kod, jak robić komentarze, a jak nazywać zmienne - lecz typowo książka nastawiona na pisanie kodu gotowego do rozbudowy.

Pewien programista powiedział mi, że programowane modułowe to takie, gdzie cały program ma ustalone standardy wyjścia-wejścia. Wszystkie moduły są nie zależne od siebie (ale świetnie, ze sobą współgrają) i zmiana jednego nie może ingerować w inny. Bardzo tym się zainteresowałam i chciałabym zaciągnąć wiedzy.

Jaka Waszym zdaniem jest najlepsza literatura uczenia się techniki programowania modułowego?

Żadna. Jak zresztą w ogóle do nauki programowania. Z książki możesz nauczyć się składni języka i to by było na tyle ;] Tylko praktyka pozwala nauczyć się programowaina. Musisz po prostu zacząć pisać komponentowo i tyle.

Co zrobić, aby stworzyć system, w którym się nie zakopie, gdzie będę mogła programować modułowo, przez co mój kod będzie bardzo uniwersalny i nastawiony na rozbudowanie?

Przemyśleć architekturę i stosować ciągły refaktoring. Nie istnieje coś takiego jak "ogólna architektura systemu komponentowego" bo kazdy system informatyczny jest inny. Możesz używać frameworków które wspierają taki czy inny model programowania, ale bez ogarnięcia w temacie nic to nie da. Tak samo jak pisanie w jakimś frameworku wspierającym MVC wcale nie znaczy że ktoś umie stosować MVC ;)

Najlepiej właśnie by było poznać taką książkę kierującą pod platformę .NET

Zapomnij o książkach. Znajdź sobie jakiś komponentowy framework do .NET i w nim pisz.

I dla jasności: to o czym piszesz to raczej programowanie komponentowe. Moduł może być źle zinterpretowany, bo zwykle jeśli mowa o "modułach" w projekcie to są to po prostu pewne części funkcjonalne systemu -> np. możesz mieć moduł związany z interfejsem webowym, moduł związany z persystencją etc. Czym innym są komponenty, czyli pewne "klocki" z których możesz składać implementacje systemu.
Przy czym nie napalałbym się na to specjalnie bo w praktyce jest dość wąski zakres sytuacji gdzie komponenty faktycznie mają sens -> np. komponenty do UI. Jeśli chodzi o pozostałe 90% każdego projektu to komponenty średnio się nadają bo są zbyt "konkretne" dla danego systemu, zeby dało sie je gdzieś reużywać.

marta1995 napisał(a):

Widziałam, że książek na ten temat jest sporo, ale chce poznać Waszą opinie i w tym miejscu uwaga, że nie chciałabym książki jak pisać czysty kod, jak robić komentarze, a jak nazywać zmienne - lecz typowo książka nastawiona na pisanie kodu gotowego do rozbudowy.

Na możliwości rozbudowy wpływa stosowanie się do powszechnych zasad OOP: DRY, SOLID, KISS i YAGNI.
Natomiast co do poprawnego podziału na moduły, to wszystko zależy od wielkości systemu i stosowanych technologii.
Poza tym, co nazywasz "modułem"? Czy nie mylisz go z warstwą?

Bardziej chodziło mi o coś co @Shalom nazywa komponentem. I tak jak on mówi przydała by się jakaś książka do tego.
I @Shalom masz racje z książki nie nauczę się, ale zdobędę teoretyczne podstawy. Z internetu nie lubię czytać, bo każdy bloger opisuje to inaczej, a często jest tak, że ludzie piszący o czymś nie mają na ten temat pojęcia - dlatego zależy mi na książce.
Ja warstwą nazywam 7 - elementowy model zaproponowany przez ISO/OSI, nic o nim nie wspomniałam.
MVC - przypadkiem nie tyczy się tylko serwisów internetowych? Przynajmniej tyle zrozumiałam, czytając czym to jest. Stosowanie ich w aplikacjach poza serwisami ma sens?

@marta1995 o_O wiesz ze dzwonią ale nie wiesz w którym kościele. Nigdzie nie napisałem że jakakolwiek książka ci się przyda ;]
Warstwa to jest przeciez ogólnie pojęcie które określa pewien "poziom". Warstwy IOS/OSI to dobry przykład, ale zauważ ze aplikacje też są budowane w modelu wielowarstwowym. W komunikacji sieciowej warstwy określają niejako kolejne poziomy abstrakcji przez które przechodzą dane - od użytkownika przez protokoły komunikacyjne aż do warstwy fizycznej. W przypadku wielowarstwowych aplikacji informacje tak samo idzie od użytkownika przez warstwę UI, później przez warstwy logiki biznesowej na przykład do warstwy dostępu do danych.
MVC/MVP/MVVM tyczy się wszystkich aplikacji z interfejsem użytkownika.

Czyli nie ma sztywno ustalonych reguł czym jest warstwa w oprogramowaniu? Czytając Twój post skojarzyło mi się coś z front-end i back-end - pewnie to są przykłady warstw o których mówisz?

Warstwa to warstwa. Możesz mieć tort który ma 10 warstw, możesz się przykryć kilkoma warstwami kołdry jak ci zimno i możesz też napisać soft który ma wiele warstw.
front i backend to niby są jakieś warstwy, ale zwykle są zbyt ogólne i zbyt szerokie żeby jako takie je traktować. Warstwa określa raczej jakiś poziom abstrakcji i w normalnej aplikacji "backend" składa się z wielu warstw.

MVC/MVP/MVVM tyczy się wszystkich aplikacji z interfejsem użytkownika.

Skoro tak, to czemu nie można znaleźć nic poza ASP? Nic o MVC dla desktopów, smartfonów i innych platform?
http://helion.pl/search?qa=&wsprzed=1&wprzyg=0&serwisyall=0&szukaj=MVC

marta1995 napisał(a):

Ja warstwą nazywam 7 - elementowy model zaproponowany przez ISO/OSI, nic o nim nie wspomniałam.

Myślałem, że wiesz, co to są warstwy, skoro pytasz o wzorce architektoniczne. Bo te wzorce mówią o tym, jak dzielić aplikację na warstwy, jak organizować komunikację między nimi, i co w tych warstwach i jak realizować.

Zacząć można tutaj: http://en.wikipedia.org/wiki/Multilayered_architecture

MVC - przypadkiem nie tyczy się tylko serwisów internetowych? Przynajmniej tyle zrozumiałam, czytając czym to jest.

Nie.

Stosowanie ich w aplikacjach poza serwisami ma sens?

Serwis oznacza usługę. Aplikacje składają się z serwisów, choć mogą też korzystać z zewnętrznych serwisów. Można mieć usługi webowe, a można mieć klasy służące innym klasom, i to wszystko są serwisy. A Ty o co pytasz?

marta1995 napisał(a):

MVC/MVP/MVVM tyczy się wszystkich aplikacji z interfejsem użytkownika.

Skoro tak, to czemu nie można znaleźć nic poza ASP? Nic o MVC dla desktopów, smartfonów i innych platform?
http://helion.pl/search?qa=&wsprzed=1&wprzyg=0&serwisyall=0&szukaj=MVC

Nie żartuj:
https://www.google.pl/search?q=c%23+winforms+mvc
https://www.google.pl/search?q=android+mvc

Książki traktują o TECHNOLOGIACH albo o WZORCACH. To od Ciebie zależy, którego wzorca użyjesz w danej technologii. To programista musi umieć dobrać jedno do drugiego, i z książek nie da się tego nauczyć.

Ok, już zrozumiałam. Ale widzę, że aplikację warstwowe najczęściej skłaniają się ku MVC. Czemu nie ma książek, o tym które tłumaczyłby jak oprzeć to rozwiązaniach na aplikacjach desktopowych?

A jaka jest niby różnica między aplikacją desktopową a webową w kontekście MVC? o_O Dla mnie żadna. Czemu więcej jest książek do weba? Bo 95% softu pisanego w Javie i .NET to jest Web. Prawie nie robi się softu desktopowego.

@marta1995

Pisałam, kiedy edytowałeś posta - wyniki w google widzę, ale co z tą książką... skoro tak dobrze publikują to w ASP, czemu nie mogą w WinForm, albo WPF?

Bo ASP.NET MVC to jest nazwa TECHNOLOGII firmy Microsoft, więc książki jej dotyczące mają tę nazwę w tytule. Nazwy technologii dla desktopu nie zawierają tego skrótu, więc szukając po tytułach nic o MVC w technologiach desktopowych nie znajdziesz.

Co do wspomnianej wcześniej modułowości to radził bym zawsze się dobrze zastanowić czy i w jakim zakresie będzie potrzebna. To potrafi to sporo kosztować.

Generalnie zawsze trzeba system trochę podzielić na warstwy i/lub moduły żeby mieć separation of concerns. Ale łatwo z tym przesadzić. Pytania na które trzeba sobie powiedzieć:

• czy dzielimy technicznie (repozytoria <-> usługi <-> gui) i/lub funkcjonalnie (dane podstawowe, logistyka, finanse)
• co chcemy uzyskać przez ten podział ?
  1. tylko dobrą organizacje kodu - wtedy wystarczy dobry schemat pakietów + podział kompetencji + IoC
  2. możliwość kustomizacji softu pod klienta - wtedy najlepiej podejście warstwowe + AOP + możliwość kustomizacji konfiguracji IoC + dorobienie warstwy kustomizacji dla klienta, kustomizacja przygotowana statycznie - na poziomie assembly paczki dla klienta
  3. dynamiczna rozszerzalność - obsługiwana przez użytkownika na żywym organizmie - wtedy coś w stylu np. OSGi, pełna modułowość ala to co widzimy w Eclipse - choć w systemach biznesowy to o wiele bardziej złożone

Opcja 3 wydaje się zawsze najatrakcyjniejsza ale kosztuje w cho*re. Zwłaszcza jeżeli będzie istnieć wiele zależności między poszczególnymi modułami. Zarządzanie nimi będzie kosztować. Trzeba obsłużyć podniesienie model danych / konfigu podczas dynamicznego dogrywania modułu i ciągle zastanawiać się co jeżeli klienta ma moduł A, ale wyłączył B, który rozszerzał nieco model danych A, a potem sobie dogra C, któryż dla odmiany zmienia zachowanie jakieś funkcji w A. Przy dużej granulacji modułów to już nie pomaga w organizacji kodu tylko dodaje nam złożoności, która jest w pełni zbędna jeżeli klient nie wymaga możliwości składania sobie systemu jak klocków lego.

PS. Jest jeszcze opcja 4. modułowość + konfigurowalne procesy w BPMN - magiczna architektura, w której menadżerowie zaczynają sobie wizualnie układać procesy do chwili gdy zauważają że nie wszystko da się wy-klikać. Następnie ku ich zaskoczeniu otrzymują wycenę że dorobienie klocków do ich zajebistego systemu BPMN będzie kosztowało o rząd wielkości więcej niż dorobienie procesu na sztywno w systemie.