:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Omdat ik vind dat we op kantoor toch eens moeten beginnen met het gebruik van ORM, heb ik weer eens een poging gedaan om het .NET Entity Framework te gebruiken (versie 6, maar wel op .NET 4.0 ipv 4.5).
Het voornaamste probleem waar ik tegen aanloop, is de bestaande structuur en manier van werken. Kortom: ik moet het EF zo gebruiken dat het past in onze werkwijze, in plaats van onze werkwijze aanpassen aan EF.
Simpel gezegd:
- We maken altijd eerst een database, en daarna onze code. Database first dus.
- We werken met bestaande databases, die vaak 30 GB groot zijn en een paar honderd tabellen bevatten.
Mijn eerste probleem is "database first". Dat werkt niet lekker met het feit dat we zomaar 200 tabellen kunnen hebben in een database. Een oplossing die vaak wordt geopperd op internet, is dat je dan maar een model per module moet maken. Bijvoorbeeld een model voor de boekhouding, een model voor de order module, een model voor klantonderhoud, etc.
Een groot nadeel dat ik daarvan zie, is dat deze modellen met elkaar zullen overlappen. De boekhouding verwijst immers naar klanten, maar de ondermodule ook. Tevens werkt zo'n designer niet lekker met veel tabellen.
Dit heeft mij gedreven om naar "code first" te kijken. Een oplossing die ik heb bedacht, is om entities te hergebruiken in meerdere contexten.
Dus bijvoorbeeld dat zowel in een BoekhoudContext als een OrderContext, een DbSet met Klant voorkomt. Op die manier heb ik nog maar 1 definitie van Klant. Ook heeft "code first" het voordeel dat ik gewoon lekker POCO classes heb met wat definities en / of annotations. Het is vrij clean en daar hou ik van.
Daar staat tegenover, dat "code first" zelf rommelt met de database. Het gebruikt database initializer's, het pluralise't van alles. Veel tabellen die in onze bestaande databases bestaan, zijn in enkelvoud genaamd. Een klant is een klant, en niet klanten of nog erger klants
Dingen die ik tot nu toe gedaan heb, zijn dus:
- Entities gebruiken in meerdere DbContext classes
- Pluralization uitzetten (code: modelBuilder.Conventions.Remove(Of PluralizingTableNameConvention)())
Waar ik nu heel benieuwd naar ben, is:
1. Zien jullie nadelen van het gebruiken van entity classes in meerdere DbContext classes?
Dus dat zowel een BoekhoudContext als een OrderContext class een DbSet van Klant zou kunnen hebben:
Maar ook:
2. Hoe werken jullie eigenlijk met het Entity Framework?
Ik heb tot nu toe niet echt het idee dat ik er tijd mee bespaar namelijk, omdat ik tegen heel wat hobbels aanloop met "code first". Het lijkt erg handig voor nieuwe kleine projecten, maar vrij onhandig in combinatie met grote bestaande projecten (waar ik 90% van de tijd in werk helaas).
En ik blijf iemand die een enorme voorkeur heeft voor code. Ik hou niet van designers, want mijn ervaring daarmee is - dat hoewel ze lekker snel tot een resultaat kunnen leiden - ze ook vaak een puinhoop kunnen maken van een bestaande situatie (even buiten beschouwing gelaten dat ze ook weleens Visual Studio laten crashen).
PS:
Don't mind the VB.NET code.. dat is verplicht op kantoor hier, omdat ik collega's heb die van VB6 naar VB.NET gegaan zijn. Ik heb ook 4 jaar met C# gewerkt, maar mijn collega programmeurs dus niet.
Het voornaamste probleem waar ik tegen aanloop, is de bestaande structuur en manier van werken. Kortom: ik moet het EF zo gebruiken dat het past in onze werkwijze, in plaats van onze werkwijze aanpassen aan EF.
Simpel gezegd:
- We maken altijd eerst een database, en daarna onze code. Database first dus.
- We werken met bestaande databases, die vaak 30 GB groot zijn en een paar honderd tabellen bevatten.
Mijn eerste probleem is "database first". Dat werkt niet lekker met het feit dat we zomaar 200 tabellen kunnen hebben in een database. Een oplossing die vaak wordt geopperd op internet, is dat je dan maar een model per module moet maken. Bijvoorbeeld een model voor de boekhouding, een model voor de order module, een model voor klantonderhoud, etc.
Een groot nadeel dat ik daarvan zie, is dat deze modellen met elkaar zullen overlappen. De boekhouding verwijst immers naar klanten, maar de ondermodule ook. Tevens werkt zo'n designer niet lekker met veel tabellen.
Dit heeft mij gedreven om naar "code first" te kijken. Een oplossing die ik heb bedacht, is om entities te hergebruiken in meerdere contexten.
Dus bijvoorbeeld dat zowel in een BoekhoudContext als een OrderContext, een DbSet met Klant voorkomt. Op die manier heb ik nog maar 1 definitie van Klant. Ook heeft "code first" het voordeel dat ik gewoon lekker POCO classes heb met wat definities en / of annotations. Het is vrij clean en daar hou ik van.
Daar staat tegenover, dat "code first" zelf rommelt met de database. Het gebruikt database initializer's, het pluralise't van alles. Veel tabellen die in onze bestaande databases bestaan, zijn in enkelvoud genaamd. Een klant is een klant, en niet klanten of nog erger klants
Dingen die ik tot nu toe gedaan heb, zijn dus:
- Entities gebruiken in meerdere DbContext classes
- Pluralization uitzetten (code: modelBuilder.Conventions.Remove(Of PluralizingTableNameConvention)())
Waar ik nu heel benieuwd naar ben, is:
1. Zien jullie nadelen van het gebruiken van entity classes in meerdere DbContext classes?
Dus dat zowel een BoekhoudContext als een OrderContext class een DbSet van Klant zou kunnen hebben:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| Public Class BoekhoudContext
Inherits DbContext
Public Overridable Property Boekregel() As DbSet(Of Boekregel)
Public Overridable Property Klant() As DbSet(Of Klant)
Public Sub New(connectionString As String)
MyBase.New(connectionString)
End Sub
Protected Overrides Sub OnModelCreating(modelBuilder As DbModelBuilder)
MyBase.OnModelCreating(modelBuilder)
modelBuilder.Conventions.Remove(Of PluralizingTableNameConvention)()
modelBuilder.Configurations.Add(New BoekregelMap())
modelBuilder.Configurations.Add(New KlantMap())
End Sub
End Class |
Maar ook:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| Public Class OrderContext
Inherits DbContext
Public Overridable Property Orderregel() As DbSet(Of Orderregel)
Public Overridable Property Klant() As DbSet(Of Klant)
Public Sub New(connectionString As String)
MyBase.New(connectionString)
End Sub
Protected Overrides Sub OnModelCreating(modelBuilder As DbModelBuilder)
MyBase.OnModelCreating(modelBuilder)
modelBuilder.Conventions.Remove(Of PluralizingTableNameConvention)()
modelBuilder.Configurations.Add(New OrderregelMap())
modelBuilder.Configurations.Add(New KlantMap())
End Sub
End Class |
2. Hoe werken jullie eigenlijk met het Entity Framework?
Ik heb tot nu toe niet echt het idee dat ik er tijd mee bespaar namelijk, omdat ik tegen heel wat hobbels aanloop met "code first". Het lijkt erg handig voor nieuwe kleine projecten, maar vrij onhandig in combinatie met grote bestaande projecten (waar ik 90% van de tijd in werk helaas).
En ik blijf iemand die een enorme voorkeur heeft voor code. Ik hou niet van designers, want mijn ervaring daarmee is - dat hoewel ze lekker snel tot een resultaat kunnen leiden - ze ook vaak een puinhoop kunnen maken van een bestaande situatie (even buiten beschouwing gelaten dat ze ook weleens Visual Studio laten crashen).
PS:
Don't mind the VB.NET code.. dat is verplicht op kantoor hier, omdat ik collega's heb die van VB6 naar VB.NET gegaan zijn. Ik heb ook 4 jaar met C# gewerkt, maar mijn collega programmeurs dus niet.
Ask yourself if you are happy and then you cease to be.
/u/189240/av70.png?f=community)
:strip_icc():strip_exif()/u/120006/acb1cf0156bfb0634b213bf0cb9b0ca556a60316_medium.jpg?f=community)
:strip_exif()/u/73955/foxavatar-60.gif?f=community){kind=avatar}
Dat vraag ik me soms ook af. Het gebrek aan voorbeelden vind ik nu vaak al irritant, omdat de focus ervan erg op C# ligt. En de EF Power Tools genereren alleen C# code :strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
