MVC 6, Entity Framework 7, repository/struktur

Tags:    c# mvc6 database

Hejsa

Jeg har et spørgsmål til hvordan I strukturerer jeres løsninger, når I koder i .NET. Jeg er kommet ind i en lidt træls vane med bare at fyre et MVC projekt op, tilføje en EF model og så ellers bare køre med helt tynde/dumme objekter enten i samme projekt eller evt. et separat class library, alt efter om jeg skal bruge det i andre løsninger.

Jeg er ved at være lidt træt af at placere al min logik i controllere og bryde rigtig mange af de principper, som jeg godt kender og husker fra da jeg læste, men er bare kommet så langt væk fra det, at jeg lidt har brug for jeres hjælp.

Jeg har i længere tid forsøgt at komme tilbage på sporet med fx DDD, men kan simpelthen ikke gennemskue, hvordan jeg skal koble mine lag op med MVC og fx DI. Når I bruger EF, laver I code-first og egentlige domæne-objekter med funktionalitet, eller mapper I fra et DAL-lag til jeres domæne-objekter?

Det behøver ikke være DDD, en anden ting kunne bare være at have et lag, der kan give mig fx lister, jeg bruger flere steder på sitet. Hvis jeg fx vil have alle brugere ud med "Peter" som fornavn, så gør jeg det nu, at i min controller skriver jeg bare min linq-statement og fyrer af sted og får min dumme objekter ud. Da jeg gerne vil kunne genbruge den kode, så ville jeg selvfølgelig flytte det i et lag for sig og kalde metoden fx GetCustomersByFirstName(string givenName); men hvordan gør jeg det i praksis, så DI fungerer? Jeg kunne sagtens lave et lag, som bare new'er en EF-context, men så ryger test-barhed, som jeg lige ser det.

Hvis I kender nogle gode kode-eksempler, så vil jeg meget gerne se dem, for jeg synes lidt jeg cykler rundt i ring med den samme gamle måde at gøre det på.




3 svar postet i denne tråd vises herunder
1 indlæg har modtaget i alt 1 karma
Sorter efter stemmer Sorter efter dato
Sørg for, at du har oprettet og registreret en DbContext-klasse i Startup.cs:

Fold kodeboks ind/udCSharp kode 


Lav services eller repositories til operationer som eksempelvis hent alle kunder med et bestemt fornavn.

Fold kodeboks ind/udCSharp kode 


Fold kodeboks ind/udCSharp kode 


Du registrerer så repository-interface og -implementering i Startup.cs

Fold kodeboks ind/udCSharp kode 


Nu er du klar til at bruge dit repository i en controller.

Fold kodeboks ind/udCSharp kode 


Service- eller repository-laget kan være en mappe kaldet Data, Infrastructure eller Dal i dit MVC-projekt. Er det et større projekt, kan du med fordel lægge laget som et separat projekt i din solution eller måske endda i en solution for sig selv.

Du taler om Domain-Driven Design. Jeg har kun læst op på det, ikke anvendt det i praksis, men mht. ASP.NET, så kan det se ud som følger (Onion-arkitektur):

Fold kodeboks ind/udKode 


Læs mere om Onion Architecture i ASP.NET MVC



Indlæg senest redigeret d. 04.11.2016 00:05 af Bruger #17546
Kender ikke så meget til det praktisk i at få EF og IoC-containere til at virke.

Hvis du har tynde objekter på det betyder at din logik ligger et andet sted. Måske manipulerer dine controller for meget i dine objekter, og de manipulationer kunne måske passe bedre hvis de var metoder på dine modelobjekter. Det kan også være dit domæne simpelthen bare er tyndt. F.eks., vil jeg gætte på at en enkeltmandsblog ville have et simpelt domæne, og ville f.eks. ikke forvente mange metoder på en "Kommentar" objekt.

I DDD terminologi er dine domæne objekter ikke de samme objekter som EF/ORM/DAL arbejder med (se også kommentarer til videon i linket under).

Men Jimmy Bogard har en glimrende præsentation om hvordan man gør sin domænemodel mindre "flad": https://vimeo.com/43598193 , som jeg synes du skal se hvis du ikke allerede har.



Indlæg senest redigeret d. 28.08.2016 17:44 af Bruger #14645
Oftest har du ikke lyst til dine controllere skal ret meget mere end sende dig det rigtige sted hen og returnere data til dig.
Det lyder som om dit M i MVC, er blevet til EF mere eller mindre?
For den logik du laver i din controller bør du flytte til nogle modeller der skal have logikken så du nemt kan afskære dine modeller og nemt opbygge samme logik i noget andet end MVC fx.

Så jeg ville lave logikken til at selecte dine data og dine LINQ-statements ned i nogle modeller som håndterer det og er mellemlag for din controller og dine EF-objekter.

Kan du komme med et eksempel med din testbarhed forsvinder når du laver new, for måske forstår jeg ikke hvad du mener?



t