Aplikacja komunikująca z się z bazą danych MySQL - odpowiednia architektura

Witam, chciałbym stworzyć aplikację, która będzie się łączyć z bazą danych i chciałbym to zrobić w jak najbardziej zoptymalizowany sposób, a żeby później łatwo rozbudować aplikację w razie potrzeby czy chęci dalszej pracy przy niej.

Aplikacja miałaby za zadanie:

1. Łączyć się z bazą danych
2. Wprowadzać / edytować / usuwać dane z bazy

Wedle tego co napisałem mam wizję jak poniżej:

a) Tworzę klasę MySQL, która potrafi:

• połączyć się do bazy
• wykonać zapytanie SQL
• rozłączyć się z bazą

b) Teraz wpadam na pomysł, że chce pobierać z bazy nazwy użytkowników czyli tworzę klasę User, której w konstruktorze wysyłam obiekt MySQL i tworze sobie metody:

public User(MySQL) {

}

• createNewUser()
• updateUser()
• deleteUser()

c) Za tydzień wpadam na pomysł stworzenia klasy Article i znowu wysyłam w konstruktorze obiekt MySQL i tworze odpowiednie metody...

Czy zbudowanie aplikacji w ten sposób to zło? Jak można byłoby zrobić to lepiej?

Czy zbudowanie aplikacji w ten sposób to zło?

Trochę tak, bo dziś mógłbyś tą "aplikacje" zrobić bez pisania więcej niż kilku linijek kodu. Jakieś Spring-Data-JPA postawiło by ją od kopa bez pisania kodu.
Poza tym jeśli już musisz, to zrób sobie klasyczne antyczne GenericDao<T> i musisz zaimplementować te wszystkie create, update,.... tylko raz, a potem tworzyć sobie klasy rozszerzające to Dao.

Paweł Kurzepa napisał(a):

Czy zbudowanie aplikacji w ten sposób to zło? Jak można byłoby zrobić to lepiej?

Taką aplikację robi się wykorzystując Spring Starter JPA w 30 minut. Tutaj masz przykładowy tutorial.
https://spring.io/guides/gs/accessing-data-jpa/

Wtedy klasa GenericDao miałaby łączyć się do bazy danych i zawierać metody create update etc ?
Jeżeli klasa GenericDao będzie się łączyć do bazy danych, a klasa User i Article zacznie po niej dziedziczyć to połączenie do bazy będzie następować przy każdym tworzeniu obiektu ?

Ogólnie chciałbym, aby np. program się uruchomił stworzył nowego użytkownika...przeszedł w jakiś tam czas spoczynku (może nawet pare godzin), a później odwołał się do Article - stworzył coś nowego, przeszedł w stan spoczynku ponownie teraz nie robił nic np. przez tydzień i po tygodniu utworzył kolejnego użytkownika. - Oczywiście w tym momencie aplikacja nie byłaby wyłączana przez np. tydzień.

@jumbo_jet w Javie znam tylko podstawy, a Spring to Framework - nie wiem czy ruszać framework nie poruszając się dobrze w Javie...

Jeśli mówimy o architekturze aplikacji, to baza danych jest szczegółem implementacyjnym, a Twój design wynosi tego MySQL na piedestał :) to co chcesz zrobić, to klasyczny CRUD, możesz zrobić tak jak wyżej koledzy zasugerowali. Poczytaj o architekturze warstwowej, na początek wystarczy.

No tak trochę to tak wygląda jakbym MySQL wyniósł na piedestał.

Czyli co najlepiej byłoby zrobić tak naprawdę w tego jakiś moduł / pakiet, który będzie działać jak CRUD (przy użyciu sprint-data-jpa) i potem moduły/pakiety, które będą z tego korzystać?

Ogarnij sobie to https://spring.io/guides/gs/accessing-data-jpa/ i wróć z kolejnymi pytaniami, na pewno się pojawią :) będziemy tu siedzieć i czekać

Witam ponownie, zapoznałem się z powyższą treścią faktycznie framework wydaje się być dosyć przyjemny, zarządzanie zależnościami też wygląda ok tylko mam jedno małe ,,ale".

Właściwie wcale nie chce, a żeby dostęp do aplikacji odbywał się przez stronę, a z tego co widzę Spring jakby uruchamia od razu Tomcata i robi się dostęp z poziomu przeglądarki.

Konkretnie chciałbym stworzyć aplikację, która:

1. Po uruchomieniu tworzy serwer TCP (wiadomo taki serwer musi działać wielowątkowo - co na to spring?)

2. Po uruchomieniu serwera chciałbym, stworzyć klienta TCP, który będzie odbierał dane od zewnętrznego serwera, z którym jest połączony i odebrane dane roześle do użytkowników, którzy są połączeni z serwerem, który został uruchomiony w pkt 1

3. Teraz serwer TCP (z pkt 1) na podstawie odebranych danych od użytkownika podłączonego otrzymuje jakiś komunikat, a na podstawie tego komunikatu serwer podejmuje decyzje jakie rekordy w tabeli stworzyć / edytować / usuwać

4. Klient TCP (z pkt 2) na podstawie odebranych danych od serwera zewnętrznego też może mieć potrzebę tworzenia / edycji / usuwania rekordów w tabeli

Teraz pytanie czy spring nada się do takiej aplikacji? Czy nie nastąpi problem aplikacji ze względu na prace wielowątkową?

Spring się do tego nada, tylko musisz wyłączyć domyślny serwer HTTP, a obsługę socketów zrobić na piechotę - chyba, że Spring Integration to wspiera, to wtedy wystarczy pewnie odpowiedni config, bo klasy (beany) będziesz miał z paczki. Zaletą tego podejścia będzie to, że z kolei komunikację z bazą masz ułatwioną dzięki Spring Data JPA/Jdbc. Ewentualnie kombinowałbym coś lekkiego na Nettym.