Interfejs, logika i dane. Kto, komu i w jaki sposób ;)

W jaki sposób bym nie myślał i jak bardzo wszytko udziwniał zawsze kończy się tak samo. Program składa się danych, logiki i gui. Kropka.
Nie mogę dojść do rozwiązania problemu, ciężko mi znaleźć mocne argumenty dla jednej czy drugiej opcji.
Otóż:
( Abstrakcyjny przykład, zeby lepiej sobie zobrazować problem )

• Klient ( użytkownik ) wybiera spośród dostępnych zabudowań ( GUI ) budynek ( kontrolka/okno ) i zgłasza swój akces
• Logika ( urząd/administracja ) przyjmuje zlecenie ( GUI->assigned_logic->Notify( REQUEST_ACCESS ) ) po czym pobiera od klienta niezbędne informacje ( np. Logic->control->GetValue( DataBuffer& new_data ) ).
• Urząd(logika) sięga po aktualne informacje o budynku z bazy danych ( np. Logic->DBObject->GetData( DataBuffer& actual_data ) )
• Urząd(logika) weryfikuje poprawność danych i wniosku ( czy są wolne lokale, wysokość czynsz itp. ) oraz pyta klienta o potwierdzenie (opcjonalnie), ewentualnie dodatkowe informacje.
• Jeśli wszystko jest ok urząd(logika) dodaje nowego lokatora do bazy danych ( np. Logic->DBObject->Save( new_data ) )
• Zdarzenie kończy się sukcesem i wraca do modułu logiki z danymi potrzebnymi do zaktualizowania interfejsu graficznego. W międzyczasie baza danych zapisuje cały łańcuch operacji jakie zostały wykonane w ramach tego zadania w celu możliwości
  prostego przywrócenia poprzedniego stanu ( Undo/Redo )

Kto aktualizuje strukturę bazy danych? Urząd(Logika) czy baza danych ?

Przyjmijmy, że baza danych jest zaimplementowana w postaci grafu. Węzeł STREET posiada połączenia typu/o wadze ADDRESSED_BUILDNGS, węzły BUILDNG są przyłączone do ulicy łączem typu ADMIN_STREET. Dodatkowo każdy budynek posiada łącza do wszystkich lokatorów zamieszkujących dany budynek. ( OCCUPIED_BY / LIVE_IN ). W bazie istnieją również obiekty typu SCHOOL, HOSPITAL, ADMINISTRATION, etc.
Po zdarzeniu zameldowania nowego lokatora kto "łączy" go z obiektami użyteczności publicznej w okolicy i jednocześnie "odłącza" od obiektów do których był przypisany przed przeprowadzką? Czy to moduł Logiki ma pobierać dane o użytkowniku oraz jego "kontaktach" by zadbać o poprawne połączenia czy baza danych ma to zrobić automatycznie po otrzymaniu żądania zmiany zameldowania?

Niby GUI powinno odpowiadać wyłącznie za wizualizację danych, ale jednak posiada jakąś tam hierarchię okien, pozycję czy proporcję. Czy baza danych powinna działać podobnie tzn. oprócz funkcji przechowywania suchych danych powinna "wiedzieć więcej" i wewnętrznie dostosowywać się do zdarzeń zachodzących w aplikacji czy powinna jedynie udostępniać jakiś tam interfejs logice, która by o to dbała?

Problem głupiej bazy, głupiego widoku i wszystkorobiącego kontrolera. Znaczy mvC zamiast MVC ;)

Pomyśl o tym inaczej - GUI, to nie "GUI", to Warstwa Prezentacji. Ma robić to, co mu podają. Z założenia warstwa prezentacji nie operuje na danych, ale je prezentuje. Tak samo z przyciskami czy czymś tam co wydaje komendy. To nie Warstwa prezentacji wydaje te komendy tylko informuje kontroler że uzytkownik chce aby takie coś zostało wykonane - w końcu po stronie kontrolera pewnie będzie jakieś ACL czy inne RBAC.
Z drugiej strony jest baza... To też nie "Baza" ale Model. I to nie bez powodu model. To ma modelować i reprezentować połączenia w obrębie danych w bazie. Jak by kontroler miał pro prostu mielić dane to mógłby równie dobrze mielić je bezpośrednio na bazie... Pytanie z tym co ma co wykonywać na danych jest nietrywialne, a odpowiedź zazwyczaj brzmi "to zależy". Zależy właśnie od tego jak bardzo chcesz odciążyć kontroler od mielenia danych i jak ma się model zachowywać. Może być tak że model może o siebie sam zatroszczyć, może być tak że za pomocą kontrolera itp.

Wracając do twojego przykładu: od złej strony myślisz ;) Więcej polimorfizmu i szablonowego kodu daj w swoim kodzie :) Dla przykładu: dajesz że to kontroler ma weryfikowac dane w modelu - dlaczego? To model wie czym jest i co powinien mieć. Niech sam zwaliduje dane. Dalej - traktujesz całą bazę jako model, co jest złym pomysłem. Każda tabelka ma inne dane, powiązania itp które można zobrazować obiektami (modelami). Pewnie traktujesz całe gui jako widok - też źle.

Mam nadzieje że jakoś rozjaśniłem :)

Johnny_Bit napisał(a):

Pomyśl o tym inaczej - GUI, to nie "GUI", to Warstwa Prezentacji. Ma robić to, co mu podają. Z założenia warstwa prezentacji nie operuje na danych, ale je prezentuje. Tak samo z przyciskami czy czymś tam co wydaje komendy. To nie Warstwa prezentacji wydaje te komendy tylko informuje kontroler że uzytkownik chce aby takie coś zostało wykonane - w końcu po stronie kontrolera pewnie będzie jakieś ACL czy inne RBAC.

Kontroler jest częścią warstwy prezentacji. MVC to w ogóle wzorzec dla warstwy prezentacji. I tak, widok ma być głupi bo tylko prezentuje dane. Kontroler decyduje gdzie (do jakiej części modelu) przekierować żądanie użytkownika.

Z drugiej strony jest baza... To też nie "Baza" ale Model. I to nie bez powodu model. To ma modelować i reprezentować połączenia w obrębie danych w bazie.

Model to jest model, żadna baza nie jest do niczego potrzebna. Baza jest częścią warstwy składowania danych, a raczej jedną z metod jej implementacji.

Pytanie z tym co ma co wykonywać na danych jest nietrywialne, a odpowiedź zazwyczaj brzmi "to zależy". Zależy właśnie od tego jak bardzo chcesz odciążyć kontroler od mielenia danych i jak ma się model zachowywać. Może być tak że model może o siebie sam zatroszczyć, może być tak że za pomocą kontrolera itp.

Kontroler w ogóle nie powinien mielić danych, a jedynie przekazywać je do Modelu. To w modelu są serwisy, encje, i inne takie cuda do przetwarzania danych.

Dzieki za odpowiedzi i rozjasnienie. Do kodu nic nie dodam, bo kodu zwyczajnie nie ma. Z programowaniem mam doczynienia od swieta, czyli wtedy kiedy mnie najdzie ochota ;-) Zanim cokolwiek zaczne robic to najpierw testuje rozne sposoby w dziesiatkach drobnych programikow. Okazuje sie ze dopierp po n-tej orobie zaczynam pojmowac jak poprawnie czegos uzywac i w jakich przypadkach. Idzie to wolno i czasem wydaje mi sie ze wole teoretyzowac niz klepac kod. No coz, tak to jest z hobbystami :-)