Schema de construcție a Enterprise-aplicații

Enterprise-aplicații Constructing

Când întâlniți pentru prima dată conceptul de „Enterprise-cerere“ sau „cerere în cadrul întreprinderii“, nu este de obicei suficient ca ai spus ca programator. Presupun că cauza problemei este că acesta este injectat în uz non-programatori, și de marketing sau vânzători, care de multe ori nu comunică cu dezvoltatori și lideri de afaceri. Este puțin probabil ca ei vor răspunde la tine întrebarea „De ce JSP sau Servlet se referă la Java Enterprise Edition, și nu Java Standard Edition?». După cum vedeți, nimic în neregulă cu nici un web-based. Este puțin probabil ca acestea sunt mult mai complicate decât același Swing. Dar aici ne sunt împărțite. Au existat tot felul de cadru, care ajută într-adevăr să rezolve sarcini la nivel de întreprindere. Deci, ce este atât de special despre Enterprise-aplicații. La această întrebare voi încerca să răspund în acest capitol. Poate că cineva nu este de acord cu opinia mea, dar pentru mine a fost important să înțelegem că fiecare tehnologie este proiectat pentru a rezolva anumite tipuri de probleme. În cazul în care rezolvă sarcina sa de bine, atunci este nevoie. Dacă nu - „în cuptorul ei“, așa cum ar spune profesorul Schimbării.
Dacă analizăm regulile de construcție Enterprise-aplicații, putem înțelege destul de clar ce pot fi revendicate biblioteci și tehnologii. Și ei pot chiar și într-un fel anticipa - poate dura mai mult. Pentru mult timp pentru a răspândi ideea de copac, să ne uităm la schema de construire a Enterpise aplicației (în viitor, voi spune pur și simplu „cerere“). Nu voi spune că este de necontestat, dar în experiența mea sub ea potrivit pentru aproape toate proiectele la care am participat. Da, în general, și nu cu mult diferit de sfatul profesioniștilor. Dacă luăm în considerare specificația Java EE, ideile conținute în ea va fi o suprapunere de 90%, cu desenul meu.

De ce așa și nu altfel?

Participarea mai mult de un an (dar, probabil, mai mult de un deceniu), în crearea de sisteme de întreprindere, am ajuns la o descriere generală a modului în care ar trebui să funcționeze Enterprise-aplicație. Este foarte simplu: utilizatorul trimite o comandă cu parametri, cu datele care se întâmplă ceva, și, ca urmare, utilizatorul primește un răspuns în forma stabilită unii parametri, care sunt afișate pe ecran într-un fel. Cred că această înțelegere a dus la apariția SOA - Service Oriented Architecture (SOA - Service Oriented Architecture). Este doar un nou nivel de înțelegere aceeași problemă: utilizatorul trimite o cerere - sistemul face ceva cu aceste date și returnează un rezultat. Ceea ce a adus într-un sistem SOA pentru tehnologia clădire - aceasta este înțelegerea faptului că serviciile pentru mai multe unități pot fi aceleași, și, prin urmare, nu are nici un sens să le înmulțească. Și trebuie să avem un mecanism care va face mai ușor să se conecteze serviciile deja existente. Fiecare astfel de serviciu poate fi pus în aplicare pe același principiu ca și cea a întregii aplicații în ansamblul său - și anume, împărțit în aceleași niveluri. Toate aceste niveluri ale acestei arhitecturi facilitează pur și simplu dezvoltarea și întreținerea aplicațiilor. Pentru utilizator pentru a obține ceea ce vrea să înțelegeți ce trebuie să fie luate măsuri mai clar. Si cel mai important - este ușor să se ia în considerare specificul Enterprise. Iar pentru acele aplicații caracterizate prin următoarele:

Pe baza acestor promisiuni, putem spune că aplicația trebuie să utilizeze metode foarte sofisticate de stocare, prelucrare și raportare. Și, ca de obicei, în cazul în care există o cerere, există o propunere - și acest lucru este mai mult de o duzină de pachete și tehnologii. Și mai clar va fi capabil să înțeleagă problema, cu atât mai mare cercul de tehnologii familiare, cu atât mai mare numărul de pachete pe care va fi familiarizat cu, cu atât mai repede vei rezolva problemele clientului și, în consecință, cu cât ai valoare ca un profesionist.

Enterprise-schema de aplicații de construcții

Schema de construcție a Enterprise-aplicații

Singura problemă: acest sistem este conceput pentru a construi sisteme fără a utiliza componenta principală a unui SOA - ESB (Enterprise Service Bus). Dacă utilizați SOA, sistemul nu va arata exact, dar acest lucru este „o poveste foarte diferită.“ Cu toate că o parte a acestui sistem poate fi utilizat și în cazul SOA.

Nivelul de stocare - Persistența Layer și DataSource

DataSource Bunch și Persistența Layer este proiectat pentru a lucra cu datele. Mai mult decât atât, datele, așa cum se arată în figură, pot fi stocate nu numai în baza de date. Acesta poate fi fișier XML sau un fișier text. Acest lucru poate fi un server de e-mail. Sau Excel-fișier. În general, acesta poate fi orice doriți - atâta timp cât a fost mai mult sau mai puțin spațiu de stocare permanentă.
Pentru a putea face abstracție de un anumit magazin de date este utilizat un astfel de lucru ca DataSource - sursa de date, care ascunde de obicei ceva mai mult sau mai puțin tangibile - o bază de date specifică, fișier, sau altceva. Conceptul DataSource servește rolul unui pod între Persistența Layer și stocarea reală. De fapt, există chiar și o clasă specială - javax.sql.DataSource. El este utilizat pentru clauza sodaniya o conexiune la baza de date - citit despre ea, are sens. Dar, în plus față de această „abstractizare“ există un model de design foarte important - Data Access Object (DAO). Aspectul său se datorează mai multe motive:

  • Sursele de date pot fi diferite.
  • Pentru a avea acces direct la seiful specifice pot utiliza diferite API
  • Includerea în logica de cod care limitează stocarea de schimbare nu este o idee bună.

Cum, atunci, DAO ajută la rezolvarea acestor probleme. Ideea de bază - pentru a determina interfața Business Layer pe care le poate utiliza pentru a accesa datele. Iar în punerea în aplicare imediată a acestei interfețe va depinde de magazin.

Schema de construcție a Enterprise-aplicații

ORM - Obiect Relația de cartografiere. Vă avertizez o dată - nu va lua în considerare cazurile de utilizare a oricărui alt dispozitiv de stocare, dar baze de date relaționale. Dar chiar și în acest caz, datele trebuie să fie obținute din depozit și prezentate într-o formă care este convenabil să se ocupe. Există deja un timp destul de lung, termenul ORM - obiect Relația de cartografiere. Mi-ar traduce ca „tabele de mapare obiect-relaționale.“ Deși inițial cuvântul „de masă“ și nu apar, dar ar fi reflectat mai precis sensul. El se referă la tehnologii care sunt la nivel de aplicație ne permit să ia în considerare intrările în tabele ca obiecte. Fiecare rând din tabel - este obiectul. Doar în această clasă de proprietăți sunt afișate în coloana din tabel. Aceste clase sunt numite Entitate - Essence. Apropo, aproape am ajuns aproape de acest lucru - am introdus clasa „Grupul“ și „Student“, care, de fapt, îndeplini o funcție foarte simplu - pentru a stoca datele dintr-un tabel. Aceste sisteme iau pe destul de plictisitor, dar este, de asemenea, funcții foarte importante - funcția punerea în aplicare a CRUD (Create, Read, Update, Delete).
Nu trebuie să scrie același tip de cod atunci când introduceți un nou record sau atunci când primește date de la masă - poate vă amintiți, am scris SQL-interogări cu parametri, a scris codul pentru completarea parametrilor, în SQL-interogare, a scris codul pentru stocarea datelor obținute din colectarea ResultSetv de obiecte un anumit tip. În mod firesc, acest inconvenient a fost observată pentru o lungă perioadă de timp și au făcut încercări de a simplifica într-un fel. Deci, au existat unele cadru, pe care le-ați auzit deja. Aici sunt cele mai renumite:

  • hiberna
  • TopLink
  • JPA - Java Persistence API
  • Obiect Java de date - JDO
  • iBatis

Nivelul de logica de afaceri - Business Layer

La acest nivel, pe de o parte, este foarte simplu, pe de altă parte - este dificil. Doar pentru că ideea și funcționalitatea lui este într-adevăr foarte simplu - efectuează procesarea datelor în conformitate cu o anumită logică - modificări, adaugă, preluări. Și nimic altceva. Pe de altă parte, există mai multe dificultăți. În primul rând - este necesar să se organizeze lucrul cu date sub formă de întreaga tranzacție (sper că este, știi). Iar al doilea - sistemul poate fi o ierarhie complexă de clase, care trebuie să fie setat (inițializa), care nu este, de asemenea, întotdeauna o sarcină banală.
Prima problemă poate fi rezolvată în mai multe moduri destul de bine:

  • EJB - Enterprise Java Beans. De fapt, fiecare clasă (metodă) care efectuează anumite acțiuni pot fi atribuite la tranzacție, care gestionează Application Server (nu uitați că Application Server trebuie să sprijine activitatea cu EJB). Acesta începe în momentul în care intră în metoda și se termină la ieșirea metodei. Cea mai recentă versiune a EJB 3.0 (din nou, în cazul în care serverul acceptă acest lucru) se descurcă cu sarcinile necesare destul de bine. obținut.
  • Foarte sincer pentru a începe o tranzacție și captura rezultatul SQL-interogări. Acest lucru este cu siguranță mai bine să nu folosească - din pădure nu vor vedea copacii. Unele lucrări de relief ar fi de a utiliza aspecte. Ideea de bază a aspectelor - este un fel de inserare de cod în diferite locuri ale programului. De exemplu, puteți defini un anumit set de metode și să definească acțiunile pentru ei la începutul și la sfârșitul lor. Și atunci când apelați metoda va fi realizată mai întâi codul de aspect și numai după aceea metoda în sine. Mai multe detalii pot fi găsite - Programare orientată-Aspect
  • Utilizați primăvară cadru. Acesta conține posibilitatea de a lucra cu diferite tipuri de tranzacții - de obicei JDBC-tranzacție, tranzacția pentru Hibernate, TopLink, chiar și utilizați tranzacția pentru Application Server. Lucru este foarte convenabil, și că este foarte frumos, nu are nevoie de Application Server - poate lucra cu Tomcat obișnuită de web-server. Ceea ce este important de reținut, pentru punerea în aplicare a acestei primăvară utilizează AOP, care are

problema de inițializare poate fi rezolvată prin utilizarea conceptului IOC (Inversarea Control). Cel mai adesea, principiul de bază este numit „principiul Hollywood“ - „nu sună-mă, o să te sun.“ Cu alte cuvinte - pentru a stabili relațiile problemă de inițializare între clase în cadrul, în loc de a scrie codul de inițializare ori de câte ori este nevoie. Pentru a rezolva această problemă există o mulțime de cadru, dar acum am identificat două:

În plus față de încă dori să subliniez - act de faptul că între stratul Persistența și Business Layer, vom trece entitatea, și la alte niveluri (niveluri UI) BusinessLayer trimite / primește View.
În primul rând - este convenabil. UI trebuie având în vedere că acesta va apărea. Și pentru a arăta că nu este întotdeauna structura exactă a relațiilor dintre entitate. Deci, va trebui să se gândească la asta -, prin urmare, mai ușor de a oferi imediat o astfel de oportunitate. Este posibil ca o parte din View va fi pe structura chiar și coincid cu entitățile. Dar cel mai adesea nu se întâmplă.
În al doilea rând - ceva timp în urmă, prietenii mei stabili rapid Web-Sevices a structurii de clasă, care a dat afara entității. NetBeans Genera sincer o descriere completă de clasă. Și apoi au venit la o descoperire neplăcută. Faptul că entitatea nu întotdeauna umple dintr-o dată. Există un astfel de lucru ca un leneș-inițializare (inițializare leneș). Aceasta tehnica este adesea folosit atunci când nu aveți nevoie de toate domeniile entității imediat. Numai atunci când aceste date vor fi necesare - este o interogare a bazei de date. Dar cererea poate fi doar atunci când aveți o tranzacție deschisă. În momentul în care tranzacția se depune pentru stratul de afaceri, conversia de date pentru transmiterea de servicii web a făcut mai târziu - și există o problemă. Pe de o parte, el vrea să Entitate „doinitsializirovatsya“ în cele din urmă, iar tranzacția a fost deja închisă. apare eroare de execuție. Incomod.
Există un alt punct care adauga greutate folosi View - metode standard de transmitere prin parametrii HTTP (a se vedea mai jos «Web-client» pct.). Pentru a converti de la clase Java într-o anumită reprezentare textuală de reflecție este adesea mecanismul utilizat (posibilitatea de a obține informații cu privire la clasa - domeniile sale, metode, etc.). Deci, atunci când conversia de pachete, primirea de clasă, încercând să facă toate domeniile sale. În cazul în care orice domeniu se referă la un alt obiect, pachetul este încercarea de a obține acces la toate câmpurile obiectului. Și așa mai departe la infinit. Probabil deja ghicit ce s-ar putea confrunta cu, în cazul în care două obiecte se referă la unul pe altul. Sau, în general, există unele facilități lanț închis. O astfel de transformare pur și simplu introduceți o buclă infinită. Este cu siguranță posibil să se scrie de fiecare dată când dvs. convertor. Dar nu fi mai simplu de a scrie o clasa pentru vizualizare.
Din aceste motive și se transformă - este convenabil pentru a face clase separate pentru eliberarea la nivelul interfeței de utilizare

la nivel de procesare HTTP-cerere - Web Layer

Din anumite motive, la acest nivel atribuie adesea managementul logica de afaceri - în special pentru servlet. În opinia mea, acest lucru nu este în întregime corectă.
În primul rând - mixt de conversie a datelor c logica - toate tehnicile de a aduna într-o grămadă de gunoi și să facă. Și va trebui să o facă - pentru că nu vii Java-obiecte și HTTP obișnuit. Da, desigur, există modalități de a automatiza, dar cu toate acestea va arăta groaznic.
În al doilea rând - cine ți-a spus că nu va fi doar Web-clienții? Și dacă e Web-Sevices pentru demoni sau convenționale „groase» GUI clienții care pot comunica cu aplicarea RMI sau prin aceeași servicii web. Vei determina logica servlet? În principiu, este posibil, dar este în mod clar crește „pomoechnye“ codul.
Prin urmare, născut pentru a încredința nivelurile de Internet ale sarcină simplă de conversie de date între HTTP și Java. Singurul lucru pe care le puteți pune în continuare la nivel Web - aceasta este logica schimbării ecrane. Același model de proiectare MVC (Model-View-Controller). Dar nu este o legătură foarte puternică cu logica de afaceri. În ceea ce privește tehnologia și cadrul, care pot fi utilizate la acest nivel, că acestea sunt multe:

  • JSP + JSTL
  • JSF
  • Struts
  • primăvară
  • și mult mai mult - este dificil de a enumera

client WS (web-client service)

În general, aici mai ales o mulțime de a vorbi despre - Servais ta ar folosi orice program de la distanță - atât de frumos. Avantajele și dezavantajele acestei tehnologii, puteți căuta pe Internet. Când descriem un exemplu de crearea unui astfel de client - vom atinge pe scurt despre aceste probleme.

GUI-client

Aici totul este destul de evident, cu excepția faptului că protocolul de comunicare între serverul de aplicații și clientul poate ridica probleme, dar de obicei este RMI. În ceea ce privește vânzarea directă la GUI, aici alegerea este a ta. În opinia mea, Swing vă permite foarte mult. În plus, există SWT și marea diferitelor componente. Uita-te pe Internet.
În general, nimeni nu deranjează realizezi aplicație convențională client-server cu un client gros și baza de date. Dar întrebarea am considerat foarte pe scurt în prima parte. Deci, uita-te acolo și pe internet.

Web-client

Astăzi este una dintre cele mai populare solutii - dar pe care le va folosi pentru a construi - aici, de asemenea, alegerea este destul de mare. În mod evident, dacă doriți interfața de utilizare a fost frumos și modern, acesta va fi folosit AJAX. Desigur, de asemenea, că va trebui să utilizați un fel de bibliotecă. Ce a alege - vă decideți:

  • ExtJS
  • jQuery
  • Dojo
  • GWT
  • JSF - RichFaces, icefaces, MyFaces
  • și din nou, mult mai mult

Ce am observat în această secțiune - astfel încât acesta este un sistem de transmitere a datelor de la client la server și înapoi. în fapt, va folosi HTTP, dar nu Java obiecte. Aici astăzi alegerea nu este foarte mare:

În principiu, acest lucru este tot ce am vrut să spun în acest capitol. În cele ce urmează vom trage o schemă mai complexă a departamentului nostru personal - pentru a face mai interesant. Puteți începe - Partea 15 - noua structură de date.