Jak wypełnić lukę między projektem bazy danych a projektem interfejsu użytkownika?

Question

Wiem, jak to pytanie wygląda, ale jestem dość poważny. Próbuję stworzyć aplikację, która pomoże mi w uczeniu się baz danych (sql, zapytania, właściwy projekt bazy danych itp.). Używam w pracy projektu dla zwierząt domowych, więc muszę się skupić na faktycznych wymaganiach. Oryginalny projekt został napisany ("Frankensteined together", jak pierwotny autor powiedział) przez MS Access. Chciałbym nauczyć się, jak to zrobić lepiej za pomocą SQLite, ale nie wiem, jak odtworzyć inną dostępną funkcjonalność Access.

Korzystając z tej strony jako sposobu interakcji z programistami i programistami (nie pracuję z żadnymi), do tej pory przeczytałem całe Database Design for Mere Mortals zgodnie z zaleceniami w pytaniu this. Tak, mam ładny mały projekt bazy danych, który planuję wprowadzić za pomocą SQLite.

Sprawdziłem również, jak zaprojektować interfejs użytkownika dla aplikacji za pomocą makiet Balsamiqa, i przesłałem kilka pomysłów do mojej potencjalnej bazy użytkowników (moich rówieśników w moim zespole), aby mogli przekazać opinię.

  Database --> <insert code here> --> User Interface 

Jednak część, która spada dla mnie, to jak wypełnić lukę między dwoma projektami? Zdaję sobie sprawę, że to oczywiste miejsce, w którym pojawia się kodowanie, ale do tej pory nie zrobiłem nic z GUI. Poszukując, nie znalazłem niczego, co mogłoby mi pomóc znaleźć jako ostateczną (książkę, stronę internetową, a nawet proces do naśladowania) podczas próby napisania aplikacji.

Znam Perla do pewnego stopnia, ale użyłem go tylko do aplikacji uruchamianych z wiersza poleceń; Mógłbym użyć modułu Win32 :: GUI, ale tak naprawdę nie rozumiem różnic między programowaniem GUI i programowaniem linii poleceń, poza tym, że po prostu wiem, że są one różne.

Czy istnieje model lub przewodnik do śledzenia rozwoju GUI? Czy istnieją konkretne zasoby do powiązania aplikacji z bazą danych?

Answer 1

Ogólny wzór, który następuje w dzisiejszych czasach jest:

Database -> DAL -> BLL -> Controller -> View Model -> UI 

Gdzie

DAL == Data Access Layer (aka ORM, Object-Relational mapper) 
BLL == Business Logic Layer 

Googling każdy z tych terminów powinny dać dość dobry pomysł, gdzie zacząć. Pamiętaj, że nie zawsze potrzebujesz każdej warstwy. Na przykład model BLL i widok modelu mogą być opcjonalne, jeśli aplikacja jest wystarczająco mała.

Zobacz także kontroler widoku modelu (MVC) do tworzenia stron internetowych i rzutnik widoku modelu (MVP) lub widok modelu ViewModel (MVVM) do projektowania komputerów.

Chociaż samouczek NerdDinner jest specyficzny dla firmy Microsoft/sieci Web, zawiera wszystkie te pojęcia w jednym miejscu.

Answer 2

Middleware to inny termin, który możesz zobaczyć, rzucając wokół tego, co opisujesz.

Sama baza danych może być kombinacją kilku różnych punktach:

1. Procedury składowane - To byłyby wykorzystywane zamiast tabel bezpośredniego dostępu i zapewnia warstwę abstrakcji.
2. Tabele lub widoki - bezpośredni dostęp do nazw kolumn, które mogą być przydatne, gdy tworzysz lekką aplikację.
3. Połączenie dwóch. Niektóre tabele można uzyskać bezpośrednio, podczas gdy inne działania bazy danych odbywa się za pomocą procedur przechowywanych.

Interfejs użytkownika może być tylko warstwą prezentacji lub może być powiązany z kilkoma innymi warstwami, ponieważ można użyć kombinacji warstw ASP.Net, w tym C#, HTML i JavaScript do tworzenia aplikacji internetowych.