streamalism.org

1. Oversikt

I denne artikkelen vil vi gå gjennom hovedverdiforslaget til Spring som en av de mest populære Java-rammene.

Enda viktigere, vi vil prøve å forstå årsakene til at våren er vårt rammeverk. Detaljer om våren og dens bestanddeler har blitt dekket mye i våre tidligere opplæringsprogrammer. Derfor hopper vi over de innledende "hvordan" -delene og fokuserer hovedsakelig på "hvorfor".

2. Hvorfor bruke noe rammeverk?

Før vi begynner å diskutere spesielt på våren, la oss først forstå hvorfor trenger vi i det hele tatt å bruke noen rammer.

EN programmeringsspråk for generelle formål som Java kan støtte et bredt spekter av applikasjoner. For ikke å nevne at Java jobbes aktivt med og forbedres hver dag.

Videre er det utallige åpen kildekode og proprietære biblioteker som støtter Java i denne forbindelse.

Så hvorfor trenger vi tross alt et rammeverk? Ærlig talt er det ikke helt nødvendig å bruke et rammeverk for å utføre en oppgave. Men det anbefales ofte å bruke en av flere grunner:

• Hjelper oss fokusere på kjerneoppgaven i stedet for kjeleplaten assosiert med det
• Samler år med visdom i form av designmønstre
• Hjelper oss å overholde bransjen og regulatoriske standarder
• Tar ned de totale eierkostnadene for applikasjonen

Vi har nettopp skrapet overflaten her, og vi må si at fordelene er vanskelige å ignorere. Men det kan ikke være alle positive, så hva er fangsten:

• Tvinger oss til skrive en søknad på en bestemt måte
• Binder seg til en spesifikk versjon av språk og biblioteker
• Legger til applikasjonens ressursavtrykk

Oppriktig, det er ingen sølvkuler i programvareutvikling, og rammer er absolutt ikke noe unntak fra det. Så valget av hvilket rammeverk eller ingen som skal drives fra sammenhengen.

Forhåpentligvis vil vi være bedre i stand til å ta denne avgjørelsen med hensyn til våren i Java mot slutten av denne artikkelen.

3. Kort oversikt over vårens økosystem

Før vi begynner vår kvalitative vurdering av Spring Framework, la oss se nærmere på hvordan Spring økosystem ser ut.

Våren ble til et sted i 2003 i en tid da Java Enterprise Edition utviklet seg raskt og utviklet en bedriftsapplikasjon var spennende, men likevel kjedelig!

Spring startet som en Inversion of Control (IoC) container for Java. Vi forholder fortsatt vår mest til det, og faktisk utgjør det kjernen i rammeverket og andre prosjekter som er utviklet på toppen av det.

3.1. Vårramme

Vårrammen er delt inn i moduler som gjør det veldig enkelt å velge og velge deler som skal brukes i alle applikasjoner:

• Core: Tilbyr kjernefunksjoner som DI (Dependency Injection), Internationalization, Validation, and AOP (Aspect Oriented Programming)
• Datatilgang: Støtter datatilgang gjennom JTA (Java Transaction API), JPA (Java Persistence API) og JDBC (Java Database Connectivity)
• Internett: Støtter både Servlet API (Spring MVC) og nylig reaktivt API (Spring WebFlux), og støtter i tillegg WebSockets, STOMP og WebClient
• Integrasjon: Støtter integrasjon til Enterprise Java gjennom JMS (Java Message Service), JMX (Java Management Extension) og RMI (Remote Method Invocation)
• Testing: Bred støtte for enhet- og integrasjonstesting gjennom Mock Objects, Test Fixtures, Context Management og Caching

3.2. Vårprosjekter

Men det som gjør våren mye mer verdifull er et sterkt økosystem som har vokst rundt det gjennom årene, og som fortsetter å utvikle seg aktivt. Disse er strukturert som vårprosjekter som er utviklet på toppen av vårrammen.

Selv om listen over vårprosjekter er lang og den stadig endrer seg, er det noen få som er verdt å nevne:

• Boot: Gir oss et sett med veldig meningsfylt, men utvidbar mal for å lage forskjellige prosjekter basert på Spring på nesten ingen tid. Det gjør det veldig enkelt å lage frittstående fjærapplikasjoner med innebygd Tomcat eller en lignende container.
• Cloud: Gir støtte for å enkelt utvikle noen av de vanlige distribuerte systemmønstrene som funn av tjenester, strømbryter og API-gateway. Det hjelper oss å redusere innsatsen for å distribuere slike kjelemønstre på lokale, eksterne eller til og med administrerte plattformer.
• Sikkerhet: Gir en robust mekanisme for å utvikle autentisering og autorisasjon for prosjekter basert på våren på en svært tilpassbar måte. Med minimal deklarativ støtte får vi beskyttelse mot vanlige angrep som øktfiksering, click-jacking og forfalskning på tvers av nettsteder.
• Mobil: Tilbyr muligheter for å oppdage enheten og tilpasse applikasjonsatferden deretter. I tillegg støtter den enhetsbevisst visningsadministrasjon for optimal brukeropplevelse, administrasjon av nettstedsinnstillinger og bytte av sted.
• Batch: Tilbyr et lett rammeverk for utvikling av batchapplikasjoner for virksomhetssystemer som dataarkivering. Har intuitiv støtte for planlegging, omstart, hopping, innsamling av beregninger og logging. I tillegg støtter oppskalering for jobber med høyt volum gjennom optimalisering og partisjonering.

Unødvendig å si at dette er en ganske abstrakt introduksjon til hva våren har å tilby. Men det gir oss nok grunnlag med hensyn til Spring organisasjon og bredde til å ta diskusjonen videre.

4. Vår i aksjon

Det er vanlig å legge til et hei-verdensprogram for å forstå enhver ny teknologi.

La oss se hvordan Våren kan gjøre det til en turgåing å skrive et program som gjør mer enn bare hei-verden. Vi oppretter et program som vil eksponere CRUD-operasjoner som REST API-er for en domeneenhet som ansatt støttet av en database i minnet. Dessuten beskytter vi mutasjonsendepunktene våre ved hjelp av grunnleggende godkjenning. Endelig kan ingen applikasjoner virkelig være komplett uten gode, gamle enhetstester.

4.1. Prosjektoppsett

Vi setter opp vårt Spring Boot-prosjekt ved hjelp av Spring Initializr, som er et praktisk online verktøy for å starte opp prosjekter med de riktige avhengighetene. Vi legger til Web, JPA, H2 og Security som prosjektavhengigheter for å få Maven-konfigurasjonen riktig.

Mer informasjon om bootstrapping er tilgjengelig i en av våre tidligere artikler.

4.2. Domenemodell og utholdenhet

Med så lite å gjøre er vi allerede klare til å definere domenemodellen og utholdenheten.

La oss først definere Ansatt som en enkel JPA-enhet:

@Entity offentlig klasse Ansatt {@Id @GeneratedValue (strategi = GenerationType.AUTO) privat Lang id; @NotNull privat streng fornavn; @NotNull privat streng etternavn; // Standardkonstruktør, getters og setters}

Legg merke til den automatisk genererte ID-en som vi har tatt med i enhetsdefinisjonen vår.

Nå må vi definere et JPA-depot for enheten vår. Det er her Spring gjør det veldig enkelt:

offentlig grensesnitt EmployeeRepository utvider CrudRepository {List findAll (); }

Alt vi trenger å gjøre er å definere et grensesnitt som dette, og Våren JPA vil gi oss en implementering med standard og tilpassede operasjoner. Ganske ryddig! Finn flere detaljer om å jobbe med Spring Data JPA i de andre artiklene våre.

4.3. Kontroller

Nå må vi definere en webkontroller for å rute og håndtere innkommende forespørsler:

@RestController offentlig klasse EmployeeController {@Autowired private EmployeeRepository repository; @GetMapping ("/ ansatte") offentlig liste getEmployees () {return repository.findAll (); } // Andre håndterere av CRUD-endepunkter}

Virkelig, alt vi måtte gjøre var kommentere klassen og definere rutemetainformasjon sammen med hver behandlingsmetode.

Arbeid med Spring REST-kontrollere er dekket i detaljer i vår forrige artikkel.

4.4. Sikkerhet

Så vi har definert alt nå, men hva med å sikre operasjoner som å opprette eller slette ansatte? Vi ønsker ikke uautentisert tilgang til disse endepunktene!

Spring Security skinner virkelig i dette området:

@EnableWebSecurity offentlig klasse WebSecurityConfig utvider WebSecurityConfigurerAdapter {@ Override-beskyttet ugyldig konfigurering (HttpSecurity http) kaster Unntak {http .authorizeRequests () .antMatchers (HttpMethod.GET, "/ ansatte", "/ ansatte / **") .permitA. anyRequest () .authenticated () .and () .httpBasic (); } // andre nødvendige bønner og definisjoner}

Det er flere detaljer her som krever oppmerksomhet for å forstå, men det viktigste å merke seg er den deklarative måten vi bare har tillatt GET-operasjoner ubegrenset på.

4.5. Testing

Nå har vi gjort alt, men vent, hvordan tester vi dette?

La oss se om våren kan gjøre det enkelt å skrive enhetstester for REST-kontrollere:

@RunWith (SpringRunner.class) @SpringBootTest (webEnvironment = WebEnvironment.RANDOM_PORT) @AutoConfigureMockMvc offentlig klasse EmployeeControllerTests {@Autowired private MockMvc mvc; @Test @WithMockUser () offentlig ugyldig gittNoEmployee_whenCreateEmployee_thenEmployeeCreated () kaster Unntak {mvc.perform (post ("/ ansatte"). Innhold (ny ObjectMapper (). WriteValueAsString (ny ansatt ("Først", "Siste")). csrf ())) .contentType (MediaType.APPLICATION_JSON) .accept (MediaType.APPLICATION_JSON)). andExpect (MockMvcResultMatchers.status () .isCreated ()). and Exppect (jsonPath ("$. firstName", is ("First") ogExpect (jsonPath ("$. lastName", er ("Last"))); } // andre tester etter behov}

Som vi kan se, Våren gir oss den nødvendige infrastrukturen for å skrive enkle enhets- og integrasjonstester som ellers er avhengig av vårkonteksten som skal initialiseres og konfigureres.

4.6. Kjører applikasjonen

Til slutt, hvordan kjører vi dette programmet? Dette er et annet interessant aspekt av Spring Boot. Selv om vi kan pakke dette som en vanlig applikasjon og distribuere tradisjonelt på en Servlet-container.

Men hvor er gøy dette det! Spring Boot kommer med en innebygd Tomcat-server:

@SpringBootApplication public class Application {public static void main (String [] args) {SpringApplication.run (Application.class, args); }}

Dette er en klasse som kommer forhåndsopprettet som en del av bootstrap og har alle nødvendige detaljer for å starte dette programmet ved hjelp av den innebygde serveren.

Dessuten kan dette tilpasses.

5. Alternativer til våren

Selv om det er relativt lettere å velge å bruke et rammeverk, kan det ofte være skremmende å velge mellom rammeverk med valgene vi har. Men for det må vi i det minste ha en grov forståelse av hvilke alternativer som er tilgjengelige for funksjonene som Spring har å tilby.

Som vi diskuterte tidligere, Vårrammeverket sammen med prosjektene tilbyr et bredt utvalg for en bedriftsutvikler å velge mellom. Hvis vi gjør en rask vurdering av moderne Java-rammer, kommer de ikke engang i nærheten av økosystemet som Spring gir oss.

For bestemte områder danner de imidlertid et overbevisende argument å velge som alternativer:

• Veiledning: Tilbyr en robust IoC-container for Java-applikasjoner
• Spill: Passer ganske passende som et web-rammeverk med reaktiv støtte
• Dvalemodus: Et etablert rammeverk for datatilgang med JPA-støtte

Annet enn disse er det noen nylige tillegg som tilbyr bredere støtte enn et bestemt domene, men som fortsatt ikke dekker alt som Spring har å tilby:

• Micronaut: Et JVM-basert rammeverk skreddersydd mot sky-native mikrotjenester
• Quarkus: En new age Java-stack som lover å gi raskere oppstartstid og et mindre fotavtrykk

Åpenbart er det verken nødvendig eller gjennomførbart å gjenta listen helt, men vi får den brede ideen her.

6. Så hvorfor velge vår?

Til slutt har vi bygget all den nødvendige konteksten for å løse vårt sentrale spørsmål, hvorfor vår? Vi forstår måtene et rammeverk kan hjelpe oss med å utvikle komplekse bedriftsapplikasjoner.

Videre forstår vi alternativene vi har for spesifikke bekymringer som nett, datatilgang, integrering når det gjelder rammeverk, spesielt for Java.

Nå, hvor skinner våren blant alle disse? La oss utforske.

6.1. Brukervennlighet

En av de viktigste aspektene ved ethvert rammes popularitet er hvor enkelt det er for utviklere å bruke det. Spring gjennom flere konfigurasjonsalternativer, og Convention over Configuration gjør det veldig enkelt for utviklere å starte og deretter konfigurere nøyaktig det de trenger.

Prosjekter som Spring Boot har gjort bootstrapping til et komplekst Spring-prosjekt nesten trivielt. For ikke å nevne, den har utmerket dokumentasjon og opplæringsprogrammer for å hjelpe alle med å komme ombord.

6.2. Modularitet

Et annet viktig aspekt av vårens popularitet er dens svært modulære natur. Vi har muligheter for å bruke hele vårrammen eller bare nødvendige moduler. Videre kan vi eventuelt inkludere ett eller flere vårprosjekter avhengig av behovet.

Dessuten har vi muligheten til å bruke andre rammer som Hibernate eller Struts også!

6.3. Overensstemmelse

Selv om våren støtter ikke alle Jakarta EE-spesifikasjoner, den støtter alle teknologiene, forbedrer ofte støtten over standardspesifikasjonen der det er nødvendig. For eksempel støtter Spring JPA-baserte repositorier og gjør det dermed trivielt å bytte leverandør.

Videre støtter Spring bransjespesifikasjoner som Reactive Stream under Spring Web Reactive og HATEOAS under Spring HATEOAS.

6.4. Testbarhet

Vedtakelse av ethvert rammeverk avhenger i stor grad også av det faktum at hvor enkelt det er å teste applikasjonen som er bygget oppå den. Vår i kjernen forfekter og støtter testdrevet utvikling (TDD).

Vårapplikasjon består hovedsakelig av POJOer, noe som naturlig gjør enhetstesting relativt mye enklere. Imidlertid gir Spring Mock Objects for scenarier som MVC der enhetstesting blir komplisert ellers.

6.5 Modenhet

Våren har en lang historie med innovasjon, adopsjon og standardisering. Gjennom årene har det blitt moden nok til å bli en standardløsning for de vanligste problemene møtt i utviklingen av store bedriftsapplikasjoner.

Det som er enda mer spennende er hvor aktivt den utvikles og vedlikeholdes. Støtte for nye språkfunksjoner og bedriftsintegrasjonsløsninger utvikles hver dag.

6.6. Samfunnsstøtte

Sist, men ikke minst, overlever ethvert rammeverk eller bibliotek industrien gjennom innovasjon, og det er ikke noe bedre sted for innovasjon enn samfunnet. Våren er en åpen kildekode ledet av Pivotal Software og støttet av et stort konsortium av organisasjoner og individuelle utviklere.

Dette har betydd at den forblir kontekstuell og ofte futuristisk, noe som tydelig fremgår av antall prosjekter under paraplyen.

7. Årsaker Ikke å bruke våren

Det er et bredt utvalg av applikasjoner som kan dra nytte av et annet nivå av vårbruk, og som endrer seg så raskt som våren vokser.

Vi må imidlertid forstå at våren som alle andre rammer er nyttig for å håndtere kompleksiteten i applikasjonsutvikling. Det hjelper oss med å unngå vanlige fallgruver og holder applikasjonen vedlikeholdbar når den vokser over tid.

Dette koster ekstra ressursavtrykk og læringskurve, uansett hvor lite det måtte være. Hvis det virkelig finnes et program som er enkelt nok og ikke forventes å bli komplekst, kan det kanskje være mer fordelaktig å ikke bruke noen rammer i det hele tatt!

8. Konklusjon

I denne artikkelen diskuterte vi fordelene ved å bruke et rammeverk i applikasjonsutvikling. Vi diskuterte videre spesielt spesielt Spring Framework.

Mens vi var på emnet, så vi også på noen av de alternative rammene som er tilgjengelige for Java.

Til slutt diskuterte vi årsakene som kan tvinge oss til å velge våren som det valgte rammeverket for Java.

Vi bør imidlertid avslutte denne artikkelen med et råd. Uansett hvor overbevisende det kan høres ut, det er vanligvis ingen eneste løsning som passer alle innen programvareutvikling.

Derfor må vi bruke vår visdom i å velge de enkleste løsningene for de spesifikke problemene vi ønsker å løse.