Podejście programistyczne: interfejs użytkownika czy model domeny?

Chociaż nigdy nie dostarczałem niczego za pomocą Smalltalk, mój krótki czas na zabawie z nim zdecydowanie pozostawił swoje piętno. Jedynym sposobem na opisanie tego doświadczenia jest MVC tak, jak powinno być. Zasadniczo wszystkie ciężkie podnoszenie aplikacji odbywa się w obiektach biznesowych (lub modelu domeny, jeśli masz na to ochotę). Standardowe formanty są w jakiś sposób powiązane z obiektami biznesowymi. Na przykład pole tekstowe jest mapowane na pole obiektu (samo pole jest obiektem, więc łatwo to zrobić). Przycisk zostałby zmapowany na metodę. Wszystko to odbywa się za pomocą bardzo prostego i naturalnego API. Nie musimy myśleć o wiązaniu obiektów itp. To po prostu działa.

Jednak w wielu nowszych językach i interfejsach API musisz myśleć z zewnątrz. Najpierw w C ++ i MFC, a teraz w C # i WPF, Microsoft ma swój świat programistów uzależniony od konstruktorów GUI, w których tworzysz swoją aplikację, wdrażając procedury obsługi zdarzeń . Programowanie w Java Swing nie różni się tak bardzo, tylko ty piszesz kod, aby sam utworzyć instancję formantów w formularzu. W przypadku niektórych projektów może nawet nie istnieć model domeny - tylko programy obsługi zdarzeń. Byłem w tym modelu przez większość mojej kariery.

Każda droga zmusza cię do innego myślenia. Dzięki podejściu Smalltalk Twoja domena jest inteligentna, a GUI jest głupi. Przy domyślnym podejściu VisualStudio GUI jest inteligentny, a model domeny (jeśli istnieje) jest raczej anemiczny.

Wielu programistów, z którymi pracuję, widzi wartość w podejściu Smalltalk i próbuje podchodzić do tego podejścia w środowisku VisualStudio. WPF ma pewne funkcje dynamicznego wiązania, które to umożliwiają; ale są ograniczenia. Nieuchronnie część kodu należącego do modelu domeny kończy się na klasach GUI.

Więc w jaki sposób projektujesz / rozwijasz swój kod? Dlaczego?

• GUI pierwszy. Interakcja użytkownika jest najważniejsza.
• Domena najpierw. Muszę upewnić się, że system jest poprawny, zanim umieścimy na nim interfejs użytkownika.

Oba podejścia mają zalety i wady. Model domeny pasuje tam z kryształowymi katedrami i ciastem na niebie. GUI pasuje tam szybko i brudnie (czasem naprawdę brudno).

I dla dodatkowej premii: Jak upewnić się, że kod można utrzymać?

Ani

Przez lata, gdy tworzyłem oprogramowanie, zacząłem ćwiczyć obie pierwsze metodologie, ponieważ zawsze istnieje „środek”, który należy wziąć pod uwagę. Umieść interfejs między kodem interfejsu użytkownika a kodem biznesowym i uzgodnij, czego interfejs użytkownika potrzebuje w tej chwili z domeny.

Pozwólcie, że przedstawię cyfrę, która uczyni tę koncepcję krystalicznie czystą:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

W ten sposób możesz iteracyjnie pracować nad interfejsem użytkownika i modelem domeny osobno, jeśli w środkowej płaszczyźnie jest jasne, jakie dane może otrzymać interfejs użytkownika.

Powodem widzę dlaczego niektóre projekty stają unmaintainable dlatego interfejs między danych i prezentacji został rzucili czy nieistniejące (z obsługą kodu jest w interfejsie dane bezpośrednie). Widziałem tak wiele projektów, w których kod bazy danych znajdował się wewnątrz kodu formularza, że ​​straciłem wiarę w ludzkość. Tylko kilka projektów, które widziałem, które mają ten sztywny środek, przywraca utraconą wiarę.

Tak naprawdę nie ma znaczenia, od którego końca zaczniesz jako pierwszy ... ważne jest to, że masz wyraźne oddzielenie obaw. Ten kontrakt pośrodku określa prawie konkretną aplikację lub system. Pomyśl o tym, zanim przejdziesz od dołu do góry lub z góry na dół .

Domena najpierw. Muszę upewnić się, że system jest poprawny, zanim umieścimy na nim interfejs użytkownika.

Nic innego nie może sprawić, że zadziała - z wyjątkiem prostych przypadków.

Zaczynając od interfejsu użytkownika, często powstaje kruche, błędne oprogramowanie, które może wyglądać zabawnie, ale często ma poważne problemy w modelu.

Nie jest rzeczą oczywistą, że interfejs użytkownika jest skazany na niepowodzenie - jeśli model jest wystarczająco prosty, interfejs użytkownika można zbudować jako pierwszy, mając pewność, że model dobrze się sprawdzi.

W każdym przypadku, gdy nie można sobie wyobrazić modelu, należy go najpierw zbudować.

W najgorszym przypadku jakiś programista uważa, że ​​może sobie wyobrazić model. Mogły pominąć ważne szczegóły, specjalne przypadki, wyjątki lub względy wydajności. Ponieważ GUI zostało już zbudowane i pominięto wiele rozważań, model jest okropny.

To naprawdę zależy od aplikacji.

Jeśli budujesz zamkniętą aplikację klient / serwer, wystarczy jedno z podejść; gdy zamierzasz manipulować tylnym końcem, aby dopasować go do potrzeb frontów, nieuchronnie.

Jeśli budujesz otwartą aplikację klient / serwer, w której potencjalna usługa sieciowa zostanie ujawniona do użytku przez twoich klientów, wiedza o tym, w jaki sposób klient może korzystać z tej usługi w celu opracowania interfejsu użytkownika, ma kluczowe znaczenie.

Często w późnej fazie, jeśli chodzi o przyspieszenie małych cyklów iteracyjnych (Scrum, Kanban itp.), Przód i tył są wykonywane równolegle. Chodzi o zapewnienie tego, czego potrzebujesz do danej iteracji; ignorując kompilację, na wypadek, gdybyśmy tego potrzebowali . W podejściu równoległym oba końce pozostają znacznie bliżej rozwoju, co może złagodzić potrzebę ciągłych zmian, gdy przód i tył łączą się. To jest moje preferowane podejście, gdy jest to możliwe.

Wspomniałeś...

... WPF ma pewne funkcje dynamicznego wiązania, które to umożliwiają; ale są ograniczenia. Nieuchronnie część kodu należącego do modelu domeny kończy się na klasach GUI ...

Nie jesteś pewien, co przez niektórych rozumiesz ? Zarówno WPF, jak i SL są znane ze swojej funkcjonalności wiązania. To jest nieograniczone. Jeśli jesteś zmuszony umieścić kod w swoim Widoku w aplikacji WPF opartej na MVVM, wówczas coś wymaga rozwiązania. Dołączone zachowania to jeden ze sposobów na wdrożenie zachowania bez wiązania się ze zdarzeniami w widoku, a także wiele innych podejść do zapewnienia, że ​​widok pozostaje czysty.

Interfejs użytkownika z pozycji interakcji użytkownika nie powinien mieć nic wspólnego z implementacją zaplecza. Jedynym zadaniem zaplecza dla interfejsu jest dostarczanie danych poprzez przetwarzanie danych lub w inny sposób. Wiąże się to z rodzajem opracowywanej aplikacji.

Zapewnienie, że kod źródłowy jest łatwy do utrzymania, jest naprawdę zupełnie innym pytaniem samo w sobie. Na wysokim poziomie odnosi się do najlepszych praktyk kodowania wraz z przestrzeganiem sprawdzonych wzorców, architektur i technologii.

Wolę najpierw zaprojektować podstawowy interfejs użytkownika (nawet jeśli jest on tylko w wersji papierowej), z wkładem klienta. Klient może nie wiedzieć, czego chce, dopóki tego nie zobaczy. Nie zawsze możesz ufać temu, co mówi ci klient. Możesz poświęcić tygodnie na napisanie solidnego modelu domeny tylko po to, aby dowiedzieć się, że nie pasuje on do tego, co klient wymyślił, gdy chce zobaczyć prototypy interfejsu użytkownika.

Staramy się prowadzić nasze oprogramowanie za pomocą automatycznych testów. Zautomatyzowane testowanie interfejsu użytkownika zajmuje dużo czasu. Skrypty sprawdzające niektóre wartości na konsoli są łatwiejsze.

Mając to na uwadze, staramy się trzymać logikę biznesową oddzielnie od interfejsu użytkownika.

Pamiętam, jak kiedyś nawet główny programista krzyczał na mnie, że architektura Document / View została uznana za przestarzałą, gdy zasugerowałem, że musimy przestać wiązać cały nasz kod biznesowy z interfejsem użytkownika (i wtedy korzystaliśmy z win32 w C ++, więc programowanie metodą przeciągnij i upuść to nie był nawet nasz problem). Byłem po prostu oszołomiony.

IMNSHO, po prostu nie ma wymówki, aby nie mieć przynajmniej warstwy biznesowej kontra interfejs użytkownika. Jeśli twój produkt robi coś delikatnie interesującego, absolutnie konieczne jest to oddzielenie, aby umożliwić ponowne użycie kodu.

Jako programista C #, zdecydowanie nie sądzę, że jesteś zaszufladkowany do pracy na zewnątrz. Właściwie wolę najpierw zrobić model domeny.

W przypadku WPF jedynym minusem opisanego przeze mnie modelu jest to, że czasami trzeba pośredniczyć między interfejsem użytkownika a modelem domeny. Mimo to, choć czasem oznacza to więcej pracy, oznacza to również czystszy kod.

Oczywiście najpierw domena!

Piękno Smalltalk polegało na tym, że można bardzo łatwo „prowadzić” model domeny na wiele sposobów, w tym „drukować” z obszaru roboczego lub inspektora. Dopiero gdy byłeś pewien, że Twoja domena działa zgodnie z oczekiwaniami, odważyłeś się skoncentrować na tworzeniu idealnego GUI.

Nie oznacza to, że Smalltalkers nie działał na nich jednocześnie, ale kiedy GUI nie wdrożyło logiki biznesowej, zazwyczaj naprawiłeś model domeny jako pierwszy, zamiast umieszczać specjalne przypadki w GUI.