Rammeverk

Et arbeidsmiljø [ 1 ]​ (fra det engelske rammeverket ) eller rammeverket [ 2 ]​ er et standardisert sett med konsepter, praksiser og kriterier for å nærme seg en bestemt type problem som fungerer som referanse, for å møte og løse nye problemer av lignende natur.

I programvareutvikling er et arbeidsmiljø en definert konseptuell og hjelpeteknologisk struktur, vanligvis med spesifikke programvareartefakter eller moduler , som kan tjene som grunnlag for organisering og utvikling av programvare . Vanligvis kan det inkludere programstøtte , biblioteker og et tolket språk , blant andre verktøy, for å hjelpe til med å utvikle og knytte sammen de forskjellige komponentene i et prosjekt.

Den representerer en programvarearkitektur som modellerer de generelle relasjonene til domeneenheter, og gir en struktur og en spesiell arbeidsmetodikk, som utvider eller bruker domeneapplikasjoner. [ 3 ]

Introduksjon

Hovedmålet med rammeverk er å tilby definert, selvstendig funksjonalitet, bygget ved hjelp av designmønstre, og deres hovedkarakteristikk er deres høye kohesjon og lave kobling.

For å få tilgang til denne funksjonaliteten bygges deler, objekter, kalt varme objekter, som kobler systemets behov med funksjonaliteten det gir.

Denne funksjonaliteten består av såkalte kalde objekter, som gjennomgår liten eller ingen endring i rammeverkets levetid, noe som muliggjør portabilitet mellom ulike systemer.

Noen kjente arbeidsmiljøer er Spring Framework eller Hibernate , der det vesentlige for å kalles arbeidsmiljøer er å bestå av nesten statiske objekter med funksjonalitet definert på gruppenivå av objekter og ikke som en bestanddel av disse, for eksempel i deres metoder, i så fall snakker vi om en API eller et bibliotek.

Noen bemerkelsesverdige funksjoner som kan observeres:

Grunnleggende

Det er ikke noe mer enn en programmeringsbase som tar seg av sine etterkommere (administrert på en strukturell eller overlappende måte), som muliggjør ethvert svar på behovene til medlemmene, eller i deler av en applikasjon ( web ), og dermed tilfredsstiller de vanligste behovene. av programmereren.

Arkitektur

Innenfor dette aspektet kan vi stole på model-view-controller eller MVC (Controller => Model => View), siden vi må fragmentere programmeringen vår . Vi må vurdere disse grunnleggende aspektene angående implementeringen av systemet vårt:

Modell Dette medlemmet av kontrolleren håndterer de logiske operasjonene og informasjonshåndteringen (tidligere sendt av dens stamfar), for å resultere på en forklarlig og sømløs måte. Hvert medlem må omhyggelig kalles, med sitt korrekte navn og, i prinsippet, med sin sanne natur: håndtering av informasjon, dens direkte komplementering. Utsikt Til syvende og sist er det opp til dette medlemmet av familien å tegne, eller uttrykke den ultimate formen for dataene: det grafiske grensesnittet som samhandler med programmets sluttbruker ( GUI ). Det er tross alt opp til dette medlemmet å bevise den innhentede informasjonen til den når den behandlingsansvarlige. Bare (og i utgangspunktet) forventer vi å demonstrere informasjonen. Kontroller Med denne delen kan vi kontrollere tilgangen (til og med alt) til applikasjonen vår , og dette kan inkludere: filer , skript eller programmer ; alle typer informasjon som grensesnittet tillater . Dermed kan vi diversifisere innholdet vårt dynamisk og statisk (samtidig); derfor trenger vi bare å kontrollere visse aspekter (som nevnt før).

Struktur

Inne i kontrolleren, modellen eller visningen kan data håndteres, og det er opp til hver enkelt hvordan de skal tolke og håndtere disse dataene. Det er kjent at de eneste dataene til en statisk nettadresse er: å få en fysisk fil på harddisken eller fra Internett osv., og tolket eller ikke, svarer serveren .

Modellen, i likhet med kontrolleren og visningen, håndterer alle dataene som er relatert til den (det er bare midtprosessen av separasjonen etter lag som MVC-arkitekturen tilbyr). Og bare utsikten kan demonstrere slik informasjon. Med hvilken hierarkiet til programmet allerede er generert: kontroller, modell og visning.

Logikk

Tilsynelatende må vi injisere visse objekter i deres slektninger i denne applikasjonen, først da vil de dele arv og konsistens i applikasjonen din.

Raskt, for en enkel nettapplikasjon må vi sette disse objektene:

Se også

Referanser

  1. Oscar, The Martinez Network, David L.; Acosta, Julius Caesar; Mata, Liliana E.; Bachmann, Noemi G.; Vallejos, (1. januar 2012). Blandet læring, studentsentrert e-læring og ny teknologi . Hentet 11. april 2017 . 
  2. ^ "Design og implementering av et presentasjonsrammeverk for JEE-applikasjoner" . Design og implementering av et presentasjonsrammeverk for JEE-applikasjoner . 
  3. ^ a b Riehle, Dirk (2000), Framework Design: A Role Modeling Approach , Swiss Federal Institute of Technology  .