|
|
Postat pe 30.08.2018 13:29:41
|
|
|
Astăzi am discutat cu colegii mei dacă să folosesc o combinație de @Configuration și @Bean pentru a crea boabe în Spring Boot sau să folosesc @Service și alte adnotări direct pe curs. Autorul tinde să folosească prima, adică o combinație de @Configuration și @Bean.
Să vedem mai întâi un exemplu: scopul este să creezi un model pentru SearchService.
Folosește @Service direct:
Pornește aplicația, acces la browser: http://localhost:8081/search?q=koly, afișare a paginii: ["hello", "koly"]
Moduri de a folosi @Configuration și @Bean:
Comparativ cu folosirea directă a codului @Service, există o clasă AppConfig care elimină @Service adnotările plasate deasupra ElasticSearchServiceImpl. La prima vedere, există mai mult cod și clase. Care sunt beneficiile folosirii celei din urmă?
Autorul consideră că beneficiile sunt:
Separarea preocupărilor
Folosind metode @Configuration și @Bean, crearea fasolei se face într-un singur loc, iar interfața și implementarea ei nu au nicio legătură cu crearea boabelor.
Dacă crearea bean-ului trebuie modificată, atunci trebuie doar să vizualizezi și să modifici clasa Configuration corespunzătoare și nu trebuie să mergi la Java bean corespunzător pentru a face modificări. De exemplu, uneori crearea bean-ului trebuie cooperată cu @Scope sau @Profile și trebuie doar să modifice clasa Configuration.
Serviciu unic
@service adnotare însăși își asumă două responsabilități:
Unul este crearea de fasole;
Al doilea este să identifici o clasă ca serviciu.
Indică faptul că o clasă adnotată este un "serviciu", definit inițial de Domain-Driven
Design (Evans, 2003) ca "o operațiune oferită ca o interfață care stă singură în model, fără starea încapsulată."
Mai sus este explicația lui Spring despre adnotările @Service. Acea is@Service reprezintă de fapt o operație de interfață independentă, fără stare, în DDD.
Prin cooperare @Bean și @Configuration, crearea de boabe este preluată unei clase separate, iar identitatea serviciului este transmisă interfeței și numelui clasei în Java. Acest lucru se reflectă și în Spring Data, cum ar fi Repository, care este identificat după nume, cum ar fi CrudRepository. Prin urmare, Serviciul este reflectat și prin nume. Definițiile specifice ale ierarhiei pot fi folosite pentru a oferi mai multe straturi în funcție de proiect după nume, fără a se baza pe adnotările oferite de Spring, cum ar fi stratul Mapper, stratul Validator etc.
În plus, fasolea și serviciul sunt concepte bidimensionale. Unul despre implementarea concretă și celălalt despre conceptele din DDD.
Mai flexibil
Folosind metodele @Bean, poți crea instanțe de clase în bibliotecă. Dacă folosești metoda @Service, nu vei putea adăuga @Service comentarii la clasele corespunzătoare din bibliotecă.
Cele mai puține cunoștințe
Principiul cunoașterii minime înseamnă:
Cu cât este necesară mai puțină tehnologie sau cunoștințe pentru a finaliza funcția, cu atât mai bine, pentru a asigura simplitatea proiectului și a reduce dificultatea învățării acestuia.
Deoarece nu este posibil să creezi instanțe de clase în biblioteca de clase folosind @Service, trebuie să folosești forma @Configuration și @Bean când întâlnești nevoi similare. În acest moment, există adnotări precum @Service, @Configuration și @Bean în întregul proiect, iar aceste adnotări fac același lucru, adică creează boabea.
Cu @Service, există o probabilitate mare de @Service, @Component, @Configuration și @Bean în același timp.
în timp ce folosirea @Configuration și @Bean poate elimina complet utilizarea @Service și @Component, ceea ce este în concordanță cu principiul cunoașterii minime.
În final, apropo, boabele Spring au fost create în xml și ulterior folosite Java pentru configurare. Principalul motiv pentru care nu se folosește XML este că nu este suficient de concis și nu are funcții precum verificarea la compilare, mai degrabă decât necesitatea de a distribui crearea de boabe între clase.
În concluzie, autorul preferă să folosească metode @Configuration și @Bean. |
Precedent:O metodă simplă de a șterge ecranul din linia de comandă PythonUrmător:Mai multe moduri de a folosi lacătele distribuite (redis, zookeeper, database)
|
