MVC og EntityFramework med egen ekstern datamodell

[HDSoftware]

Folkens..  Har et lite dilemma, og jeg misstenker vel at svaret er "Det spørs..:", men alikevel slenger jeg ut denne for å få noen meninger.

 

Jeg har akkurat startet med MVC. Ser at man lager modeller som representerer entitetene man bruker.  Nå har jeg brukt EntityFramework i noen år og således har jeg jo allerede modeller ferdige som representerer database og biz.  Men hva med modellene i MVC?  Er det best practice å bruke de eksisterende modellene jeg har eller bør man designe egne modeller som "bare" gjelder kontrollene og Viewene ?

 

Ved å bruke eksisterende modeller vil en jo kunen bruke eksisterende funksjonalitet som allerede er laget og man slipper jo unna en masse greier.  På den andre siden kan man jo linke inn entitene i MVC modellene og kalle de direkte derfra og heller ha properties og navigation properties som reflekterer hva man ønsker å vise.

 

Føler liksom at dette går i beina på hverandre og havner støtt og stadig i situasjonen "Dette har jeg jo fra før" og føler jo ikek akkurat at det er bra heller...

 

Tanker....

[Enthroner]

Det som er greit med å ha egene data transfer objects (DTO) er at da er du helt eksplisitt med hva du vil - og forventer - å sende over internett. Det er også lettere å håndtere f.eks injection forsøk og slikt.

 

Hvis du har et json endpoint med REST så kan en bruker teoretisk endre felter du kanskje ikke vil skal endres. Alt fra småting som f.eks et CreatedOn felt eller kanskje større ting som bonuspoengbalanse eller andre ting.

 

Selv har jeg skrevet et rammeverk for å eksplisitt skjule eller vise (whitelist vs blacklist) felter fra mine EntityFramework objekter. Men denne bruker jeg kun på små prosjekter. https://github.com/AlexanderBrevig/ExposeOrHide

 

Prosjekter av skala blir lettere å håndtere i min erfaring med et eget, eksplisitt DTO lag.

[HDSoftware]

Det som er greit med å ha egene data transfer objects (DTO) er at da er du helt eksplisitt med hva du vil - og forventer - å sende over internett. Det er også lettere å håndtere f.eks injection forsøk og slikt.

 

Hvis du har et json endpoint med REST så kan en bruker teoretisk endre felter du kanskje ikke vil skal endres. Alt fra småting som f.eks et CreatedOn felt eller kanskje større ting som bonuspoengbalanse eller andre ting.

 

Selv har jeg skrevet et rammeverk for å eksplisitt skjule eller vise (whitelist vs blacklist) felter fra mine EntityFramework objekter. Men denne bruker jeg kun på små prosjekter. https://github.com/AlexanderBrevig/ExposeOrHide

 

Prosjekter av skala blir lettere å håndtere i min erfaring med et eget, eksplisitt DTO lag.

 

Takker for innlegget og det er vel slik jeg tenker også.  Ville spørre fordi MVC som sagt er nytt og greit å ta steget i riktig retning.  Godt å vite at jeg ikke tenker helt feil da :-)

[Enthroner]

Vil bare skyte inn at MVC alene fungerer godt for å lage et underliggende API hvor hvert kall bryr seg om en, og bare en, ressurs.

Før eller siden vil du ha behov for å bry deg om flere ting på en side. F.eks en blogg med header, innhold,tags, kategorier og kommentarer.

 

Mitt tips til deg da er å ha underliggende server side API skrevet med MVC (hvor views rett og slett bare er JSON eller XML render) også kan du bruke Model View View-Model (MVVM) for selve rendringen av siden din. MVC er et gammelt pattern og er egentlig blitt misbrukt og misforstått over tid. 

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

 

Et view skal egentlig ikke bry seg så mye om hvordan ting vises, men hva som vises. Når tiden er inne for å ha flere ressurser på skjerm samtidig er det lurt å ikke prøve å tvinge MCV inn i dette, men heller benytte noe som er laget for å håndtere denne situasjonen. Enter MVVM.