[C#] Waarom zou je van EF kunnen houden?

[Ankona]

[Disclaimer: even wat frustratie van me af schrijven, hopelijk komt er ook nog een constructieve discussie op gang ]

Even wat achtergrond, ik ben al jaren C# developer (en volgens de tevreden klanten snap ik dat ook wel aardig) Door de jaren heen heb ik met verschillende technieken connecties met databases gemaakt. Vanaf DAO via Ado, Ado.net al dan niet met een active record pattern, richting de ORM's. Met NHibernate kan ik prima werken. Meer en meer word ik vooral ook fan van Dapper.

Maar...... soms (zoals nu) zit ik op een project waar ze met Entity Framework werken. Ik kan daar gewoon geen vrienden mee worden. Toch hoor je in de wandelgangen regelmatig van developers dat ze er graag mee werken. Is dat omdat ze niet beter kennen of omdat er echt iets inzit om enthousiast van te worden?

Ik erger me er in elk geval kapot aan. Ten eerste vind ik code generatie principieel fout. Als je gedeclareerd hebt wat je hebben wil zou de compiler dat zelf ook moeten kunnen snappen. Daarnaast, als die tools die zonder feedback iets wel (of niet) doen. Ik kan aan de code niet zien of iets klopt, runtime blijkt dat de mapping niet werkt etc zonder bruikbare foutmeldingen. Kortom, niets dan drama (in mijn ogen)


Dus..... EF fans... Kom maar op! (en serieus, ik leer graag van jullie - maar als ik de keus heb blijf ik vooralsnog toch echt liever bij NHibernate of Dapper)

[GrooV]

Ongeacht of EF goed of fout is maar gezien je frustraties is EF niet goed geïmplementeerd. EF 6 Code first met Migrations werkt gewoon goed en zou niet zo snel @ runtime fouten moeten geven.

Of je het altijd eens moet zijn met de query generatie van EF is een ander verhaal

Dus welke versie van EF gebruik je en werk je DB first of Code first?

Verder is Dapper niet te vergelijken met EF en NHibernate

[ Voor 11% gewijzigd door GrooV op 28-02-2018 14:22 ]

[RobIII]

Ankona schreef op woensdag 28 februari 2018 @ 14:14:
Meer en meer word ik vooral ook fan van Dapper.

^ Dat. Ik heb met EF altijd ruzie om gedaan te krijgen wat ik wil (en liefst ook nog een beetje op efficiënte manier). als je goed thuis bent in 'handcoded queries schrijven' kan er, IMHO, niks tippen aan Dapper.

We gebruiken EF her-en-der, maar ik heb er altijd ruzie mee en neig altijd meteen naar Dapper.

GrooV schreef op woensdag 28 februari 2018 @ 14:21:

Verder is Dapper niet te vergelijken met EF en NHibernate

Uiteraard; het zijn twee aardig verschillende dingen (appels en peren zeg maar) maar wat TS zegt kan ik me erg goed in vinden of ik nou code-first, database-first of zelfs model-first gebruik(te, die laatste bestaat geloof ik niet meer?). Overigens is EF bij mij wel een goeie tweede hoor. En migrations zijn wel cool en fijn om te hebben. Ook 't bekijken waard (een goeie derde voor mij zeg maar): LLBLGen

[ Voor 39% gewijzigd door RobIII op 28-02-2018 14:27 ]

[Ankona]

@GrooV
Ik werk nu met een Database first scenario. Als het werkt is het allemaal heel geinig, maar als je je model wil updaten is het altijd maar weer de vraag of het werkt. (en als het niet werkt, geen idee waarom niet en geen goede mogelijkheid om het onder de motorkap op te lossen)

Dapper is idd een heel ander concept. Veel meer verantwoordelijkheid bij de programmeur in plaats van bij het framework. Het is ook geen ORM framework in de zin dat het associaties beheert. Maar.... vaak is het een heerlijk alternatief, lekker licht, simpel en snel.

[Wailing_Banshee]

Ik ben zo'n gebruiker die EF met plezier gebruikt. Ja, het is soms stoeien om een beetje effciente manier dingen doen, maar dat vind ik juist leuk en leer ik heel veel van.

Ankona schreef op woensdag 28 februari 2018 @ 14:27:
@GrooV
Ik werk nu met een Database first scenario. Als het werkt is het allemaal heel geinig, maar als je je model wil updaten is het altijd maar weer de vraag of het werkt. (en als het niet werkt, geen idee waarom niet en geen goede mogelijkheid om het onder de motorkap op te lossen)

Het probleem met het model updaten komt mij helemaal niet bekend voor. Maar wij updaten het model ook nooit, wij gooien het leeg en maken het opnieuw. Net zo makkelijk en je kunt niets per ongeluk vergeten (wat in het begin nog wel eens gebeurde, vandaar dat we het zo doen).

Dapper is idd een heel ander concept. Veel meer verantwoordelijkheid bij de programmeur in plaats van bij het framework. Het is ook geen ORM framework in de zin dat het associaties beheert. Maar.... vaak is het een heerlijk alternatief, lekker licht, simpel en snel.

Juist die associaties is iets waarom ik graag EF gebruik. Maar het mooie van EF vind ik dat je niet persé vast zit aan één methode. Je kunt LinqToEntities gebruiken, maar ook Entity SQL, of zelfs rechtstreeks op de database. Wij gebruiken ze alle drie.

[GrooV]

@Ankona
Als je EF goed en zonder problemen wil gebruiken moet je Code first met Migrations werken. Dan hoef je ook niet meer op 2 plekken al je relaties te definiëren. En maakt EF de database zoals het het beste werkt met EF zelf.

Mocht je toch graag zelf je SQL Query willen schrijven dan kan dat ook binnen EF zie,
https://docs.microsoft.com/en-us/ef/core/querying/raw-sql

Verder is met EF Core het eea al aardig verbeterd.

Zelf ben ik overigens ook fan van Dapper maar voor veel applicaties werkt EF gewoon goed

[Batavia]

Ik zie dat met entity framework mensen gewoon linq queries kunnen schrijven. Ze hoeven dan geen SQL kennis/syntax te kennen. (en nee sql is niet moeilijk, maar er zijn gewoon mensen die veel sterker zijn in LINQ dan sql)

Ik ben het helemaal met je eens dat als je Dapper code net zosnel kan schrijven dat het resultaat veel sneller kan zijn.

Maar als je Entity framework gebruikt waar het voor bedoelt is (single entities updaten/querieen) dan heb je snel de illusie dat je zonder veel kennis er aan kunt beginnen.

[ Voor 10% gewijzigd door Batavia op 28-02-2018 14:43 ]

[Ankona]

GrooV schreef op woensdag 28 februari 2018 @ 14:33:
@Ankona
Als je EF goed en zonder problemen wil gebruiken moet je Code first met Migrations werken. Dan hoef je ook niet meer op 2 plekken al je relaties te definiëren. En maakt EF de database zoals het het beste werkt met EF zelf.

Mocht je toch graag zelf je SQL Query willen schrijven dan kan dat ook binnen EF zie,
https://docs.microsoft.com/en-us/ef/core/querying/raw-sql

Verder is met EF Core het eea al aardig verbeterd.

Zelf ben ik overigens ook fan van Dapper maar voor veel applicaties werkt EF gewoon goed

Code first is vaak niet mogelijk of niet wenselijk. (ok, dat laatste is dan weer een punt van discussie...) Soms heb je nog met klassieke applicatie landschappen te maken waarbij meerdere applicaties een centrale database delen. Dan is er niet een applicatie de eigenaar van de structuur. Verder heb je ook vaak te maken met dba'ers die schema aanpassingen willen reviewen (en vaak ook zelf uit willen voeren)
Ook heb je vaak dat een applicatie nieuw gebouwd wordt maar gebruik maakt van de bestaande tig jaar oude database.
Tot zo ver de beren op de weg van de praktijk. Natuurlijk kun je altijd argumenten opvoeren om het vanaf nu beter te doen maar helaas is niet elk team bereid mee te gaan met verbeteringen.

Puur principieel zou je nog bezwaar kunnen maken op basis van seperations of concerns. Als een applicatie de verantwoordelijkheid heeft data access te verzorgen is dat een andere verantwoordelijkheid dan de structuur te onderhouden. Dit is ook een van de redenen waarom ik me er beter bij voel om de migrations in een apart project in de solution onder te brengen, bijvoorbeeld met FluentMigrations.

Maar, je hebt gelijk als het gaat om modernere platform architecturen. Daar is de applicatie doorgaans de enige gebruiker en eigenaar van de database (met niet al te omvangrijke structuur) en kun je prima code first deze onderhouden.


Wat beterft SQL schrijven, ben ik het minder met je eens. Hoewel ik zelf een zware database achtergrond heb (en dus mijn hand niet omdraai voor een lekkere complexe sql query ) vind ik het juist goed (en de belangrijkste verantwoordelijkheid van een ORM) dat de database en de code gescheiden zijn en abstract voor elkaar zijn. Eigenlijk zou je ook in code niet te complexe linq queries wensen, je wil geen kennis over het datamodel nodig hebben om met de entities te kunnen werken. Als je een attribuut of tabel naam wijzigt in de database wil je dit op een plek in de mapping (dapper/fluent Nhibernate) aanpassen en dan werkt het. Niet dat je later runtime issues krijgt omdat er nog een stukje sql string in de code verstopt stond.

[GrooV]

Een andere library gebruiken voor migrations lost natuurlijk niks op kwa SoC. EF Migrations zou ik ook altijd in een los project doen, en je wil ook niet dat dit automatisch gebeurt ivm controle.

Wat betreft mapping, dit kan ook gewoon in EF zoals dit in Dapper kan (In dapper moet je het zelfs op meer plekken wijzigen dan EF)

Ik snap gewoon niet helemaal wat je probleem nu is met EF. Met EF geef je nu eenmaal wat meer uit handen dan met een andere ORM.

Moet je overal EF voor gebruiken? Nee natuurlijk niet, gebruik de juiste tool voor de job

[ Voor 10% gewijzigd door GrooV op 28-02-2018 15:48 ]

[whoami]

peltco schreef op woensdag 28 februari 2018 @ 14:42:
Ik zie dat met entity framework mensen gewoon linq queries kunnen schrijven. Ze hoeven dan geen SQL kennis/syntax te kennen. (en nee sql is niet moeilijk, maar er zijn gewoon mensen die veel sterker zijn in LINQ dan sql)

Vooral hier heb je het gevaar -imho- dat je al vlug een expression schrijft die niet naar een performante query kan vertaald worden.
Dat is één van de problemen die ikzelf met EF heb: het laat veel te snel toe om in-efficiente queries te schrijven.

Daarnaast ben ik zowiezo geen liefhebber van EF-DB-first. In dergelijke gevallen is NHibernate gewoon een winner. Je bent veel flexibeler in het mappen van je model naar je bestaande DB.

En wat ik ook al niet snap in EF, is de manier waarop associaties gemaakt worden. Je hebt én een navigation property én een FK - property nodig. (Tenzij dat dit ondertussen veranderd is ).

Dapper vind ik wel cool, maar kan je totaal niet vergelijken met een full-blown ORM. Voor zover ik weet is Dapper een handige tool om het resultaat van queries om te zetten naar jouw object-model, maar is er geen manier om makkelijk (out-of-the-box) data terug weg te schrijven, laat staan dat er change-tracking is.

[Kenhas]

Zal dit topic even volgen. Interessant.
Hou me er zelf beetje mee bezig op een niveau net boven de amateur klasse

Ik doe alle aanpassingen eigenlijk op het db niveau en dan model leeg en opnieuw aanmaken.
Voor mij doet EF alles wat ik wil (maar soms niet altijd efficient). Moet toegeven dat ik nog nooit met NHibernate of Dapper gewerkt heb

GrooV schreef op woensdag 28 februari 2018 @ 14:33:
@Ankona
Dan hoef je ook niet meer op 2 plekken al je relaties te definiëren. En maakt EF de database zoals het het beste werkt met EF zelf.

Mag ik even vragen wat je hiermee bedoelt ? Je definieert toch maar op één plaats (database) en dan doet EF de rest qua relaties. Of begrijp ik het verkeerd

Ankona schreef op woensdag 28 februari 2018 @ 14:14:
... Ten eerste vind ik code generatie principieel fout. ...

Wat is er daar principieel fout aan ? Spreek je dan over de efficientie van de gegenereerde code ? Dat het gewoonweg niet efficienter kan zijn dan eigen code ?

Voor de duidelijkheid : bovenstaande vragen zijn ook echt vragen. Ben echt wel benieuwd naar de antwoorden. Kan maar bijleren

[Batavia]

Vooral hier heb je het gevaar -imho- dat je al vlug een expression schrijft die niet naar een performante query kan vertaald worden.
Dat is één van de problemen die ikzelf met EF heb: het laat veel te snel toe om in-efficiente queries te schrijven.

Dat is precies het punt. Als ik een 'Klant' entity op haal, en het is er altijd maar 1 (of enkele) dan maakt het mij niet uit dat de performance 50ms meer of minder is.
De winst hier zit hem er in dat in entity framework (ook een minder ervaren ontwikkelaar) in een uur in elkaar heeft zitten. De vraag is niet of dit goed of slecht is. De vraag is waarom mensen entity framework willen gebruiken.

En ook entity framework can je heel veen tunen, maar dan moet je weer veel SQL ervaring hebben en echt snappen wat er gebeurt.

[RobIII]

whoami schreef op woensdag 28 februari 2018 @ 15:58:
maar is er geen manier om makkelijk (out-of-the-box) data terug weg te schrijven

Jawel hoor? Althans, dat hang van je definitie van "makkelijk" af Maar dat is voor een SELECT niet anders in Dapper.

C#:

public int Update(Author author)
{
    using (IDbConnection db = new SqlConnection("myconnection")
    {
        string sqlQuery = @"UPDATE Author SET 
            FirstName = @FirstName, 
            LastName = @LastName  
            WHERE Id = @Id = @Id";
        int rowsAffected = db.Execute(sqlQuery, author);
        return rowsAffected;
    }
}

[ Voor 11% gewijzigd door RobIII op 28-02-2018 16:49 ]

[AtleX]

In green-field projecten heb ik goeie ervaringen met Code First EF. Dan werkt het als een trein en zijn de migrations best handig. Ja, natuurlijk moet je een beetje opletten hoe je expressies schrijft maar dat geld toch ook voor je SQL statements? Als je die niet tuned en profiled ben je ook gewoon de sigaar.

Met EF op bestaande databases zijn mijn ervaringen wat gemengder. Vaak grote problemen met models genereren van de database en dan mis je ook nog eens zinnige xmldoc. Maar we hebben ook weleens zelf de models geschreven en heel het genereren achterwege gelaten. Dat beviel mij beter.

Uiteindelijk is het gewoon een kwestie van het juiste gereedschap kiezen toch? Soms is dat Dapper, soms is dat EF, andere keren weer NHibernate en soms is iets NoSQL-achtigs gewoon beter. En dat gereedschap kies je op basis van kennis en ervaring, daar ben je software engineer voor.

[jan-marten]

Wellicht offtopic? Als je EF zo gebruikt zou je misschien eens kunnen kijken naar EntityFramework Reverse POCO Generator.

Dit heeft ons namelijk al heel wat werk uit handen genomen met het database-first principe. Kwestie van de connectionstring invullen (als dat al nodig is) en de .tt opnieuw opslaan = alle aanpassingen in de database worden in de classes verwerkt.

Wellicht de moeite even waard.

[BugBoy]

RobIII schreef op woensdag 28 februari 2018 @ 16:47:
[...]

Jawel hoor? Althans, dat hang van je definitie van "makkelijk" af Maar dat is voor een SELECT niet anders in Dapper.

C#:

public int Update(Author author)
{
    using (IDbConnection db = new SqlConnection("myconnection")
    {
        string sqlQuery = @"UPDATE Author SET 
            FirstName = @FirstName, 
            LastName = @LastName  
            WHERE Id = @Id = @Id";
        int rowsAffected = db.Execute(sqlQuery, author);
        return rowsAffected;
    }
}

Het nadeel hiervan is dat je alsnog zelf SQL code moet schrijven. Dat hoeft niet persé slecht te zijn, maar je mist type-safety en composition. Het grote voordeel van Entity Framework vind ik dat je goed queries kan samenstellen. In gewoon SQL is het volgende bijvoorbeeld erg lastig (pseudo-code):

C#:

IQueryable<DbUser> users = dbContext.Users;
if (onlyActiveUsers)
  users = users.Where(u => u.IsActive);
if (onlyUsersWithActiveProjects)
  users = users.Where(u => u.Projects.Any(p => p.IsActive));

Als ik dit in Dapper zou willen doen, dan moet ik zelf een SQL-query samenstellen en dat is een stuk complexer. Daarbij is het in EF volledig type-safe en voorkom je dus ook typefouten (of die worden at compile-time al gevonden).

Ik heb gebruik gemaakt van Linq-2-SQL, EF (code first), EF (model first), nHibernate (wel oude versie) en Dapper. Voor eenvoudige toepassingen vind ik Dapper de fijnste oplossing, maar het is wel wat beperkt. Wordt het data-model lastiger dan had Linq-2-SQL eigenlijk altijd de voorkeur (redelijk lichtgewicht en prima als je alleen MS-SQL Server target). Helaas wordt Linq-2-SQL al tijden niet meer geupdatet. Daardoor is ook het hele async/await gebeuren niet beschikbaar. Vooral voor scalable server toepassingen vind ik async/await eigenlijk wel een must.

Om die reden gebruik ik dus tegenwoordig dus meestal toch maar Entity Framework. Voor nieuwe toepassingen meestal code-first, maar als je al een model hebt staan, dan is model-first helemaal niet zo verkeerd. Vanuit developer perspectief klinkt code-first heel fijn, maar vanuit database-admin perspectief is het niet altijd prettig. Je hebt gewoon wat minder controle over je database dan vanuit een SQL gedreven oplossing.

Het ligt er maar net aan wat de omgeving vraagt. Overigens hoor ik ook erg goede verhalen over LLBLgen pro. Wordt ontwikkeld door een goede club met goede ondersteuning en leeft al langer dan EF, Linq2SQL en Dapper bij elkaar...

[ Voor 17% gewijzigd door BugBoy op 02-03-2018 16:31 ]

[RobIII]

BugBoy schreef op vrijdag 2 maart 2018 @ 16:29:
Het nadeel hiervan is dat je alsnog zelf SQL code moet schrijven.

Voor de een is dat een nadeel, voor de ander een voordeel

BugBoy schreef op vrijdag 2 maart 2018 @ 16:29:
maar je mist type-safety

Absoluut.

BugBoy schreef op vrijdag 2 maart 2018 @ 16:29:
en composition. Het grote voordeel van Entity Framework vind ik dat je goed queries kan samenstellen. In gewoon SQL is het volgende bijvoorbeeld erg lastig (pseudo-code):

C#:

IQueryable<DbUser> users = dbContext.Users;
if (onlyActiveUsers)
  users = users.Where(u => u.IsActive);
if (onlyUsersWithActiveProjects)
  users = users.Where(u => u.Projects.Any(p => p.IsActive));

Als ik dit in Dapper zou willen doen, dan moet ik zelf een SQL-query samenstellen en dat is een stuk complexer.

Mwoah:

C#:

var result = conn.Query(@"Select *
    from [users] [u]
    inner join [projects] on ...
    where((onlyactiveusers = 0) or ([u].[isactive] = 1))
       and ((onlyuserswithactiveprojects = 0) or ([p].[isactive] = 1))", 
    new { onlyActiveUsers, onlyUsersWithActiveProjects });

Stelletje youngsters Zo (die toggle/or constructie) deden wij 'composition' voor Christus *

Don't get me wrong hoor, composition is écht wel een handig "gereedschap" voor in je gereedschapskist. Maar het is niet alsof je niet zonder kunt. En bovenstaand kun je natuurlijk ook nog eens "gewoon" met een querybuilder ofzo doen die de diverse where clauses toevoegt in je querystring zelf.

BugBoy schreef op vrijdag 2 maart 2018 @ 16:29:
Het ligt er maar net aan wat de omgeving vraagt. Overigens hoor ik ook erg goede verhalen over LLBLgen pro. Wordt ontwikkeld door een goede club met goede ondersteuning en leeft al langer dan EF, Linq2SQL en Dapper bij elkaar...

RobIII in "\[C#] Waarom zou je van EF kunnen houden?"

Verder eens hoor; EF, Linq2Sql, Dapper, LLBLGen, NHibernate, ... alles kan. Alles heeft z'n pro's en cons. Pak gewoon wat je fijn vindt werken (en right tool for the job enzo).

---

* Nog een (pseudo en offtopic ) voorbeeldje uit 't jaar kneup voor de leuk:

code:

select *
from users u
where ((@username is null) or (u.username = @username))
  and ((@isactive is null) or (u.isactive = @isactive))
  and ((@email is null) or (u.email = @email))
...

En dan had je een stored procedure "FindUser" o.i.d. met 3 argumenten:
FindUser(@username = null, @isactive = null, @email = null)
waarbij elk argument optioneel is en wanneer gespecificeerd (e.g. not null) aan de 'composition toegevoegd wordt'.

[ Voor 37% gewijzigd door RobIII op 02-03-2018 16:52 ]

[HansvDr]

Ik gebruik helemaal geen EF. Heb er nooit aan kunnen wennen en vind het vaak te traag. Ook als ik wat wil aanpassen.

Dapper of gewoon Ado geeft mij veruit de beste prestaties. En gewoon lekker SQL.

En verder heeft ooit de keuze van Stack Overflow mij overtuigd :-)

https://samsaffron.com/ar...ying+and+write+my+own+ORM

Maar goed, ieder zijn ding.

[ Voor 33% gewijzigd door HansvDr op 02-03-2018 17:29 ]

[AtleX]

HansvDr schreef op vrijdag 2 maart 2018 @ 17:21:
Heb er nooit aan kunnen wennen en vind het vaak te traag.

Traag is best relatief. Als je snel (en goed) iets kan bouwen en je performance is uiteindelijk ruim binnen de gestelde eisen, is het dan te traag? Of besteed je liever twee weken extra om die laatste miliseconden eruit te slepen? Ik ben een performance freak, maar uiteindelijk is er nog zoiets als weten wanneer je moet stoppen.

Dat gezegd hebbende, ik heb een API met EF met een aardige DB (25-30 GB ofzo?) die op een single node met 1.75 GB geheugen (jaja, Azure) gewoon strak in 35ms. een request afhandelt. Weliswaar maar net 100 keer per seconde, maar dat valt me toch niet tegen.

Wel heb ik sterk de indruk dat EF vooral met grote sets snel trager wordt. Een paar honderd records gaat, maar een paar duizend is vaak al veel trager dan je zou verwachten.

[Down]

Ankona schreef op woensdag 28 februari 2018 @ 14:14:
Ik erger me er in elk geval kapot aan. Ten eerste vind ik code generatie principieel fout. Als je gedeclareerd hebt wat je hebben wil zou de compiler dat zelf ook moeten kunnen snappen. Daarnaast, als die tools die zonder feedback iets wel (of niet) doen. Ik kan aan de code niet zien of iets klopt, runtime blijkt dat de mapping niet werkt etc zonder bruikbare foutmeldingen. Kortom, niets dan drama (in mijn ogen)

Zoals al eerder genoemd is code generation een manier om EF te gebruiken. Persoonlijk heb ik er een broertje dood aan, o.a. vanwege de door jou genoemde redenen. Ik kan me nog Linq2Sql herinneren met DBML. The horror..

Wij gebruiken voor een nieuwe interne backend EF Core 2.1. met code first en daar ben ik echt zeer over te spreken. We doen alles in principe met EF, tenzij performance echt een probleem is in welk geval we Dapper gebruiken. Verder vind ik Linq ook heel prettig werken. Alleen de left join syntax is nogal clunky, maar goed. Ik ben er in ieder geval behoorlijk productief mee en ook qua unit testing en mocking werkt het allemaal erg prettig. Over 'vanilla' EF kan ik overigens niet meepraten, maar wellicht is het daar anders.

We hebben wat domme POCO's en naming conventions, verder is het echt extreem weinig configuratie en daarna gewoon IQueryables aftrappen . Alle output SQL wordt overigens wel gelogd en ik check altijd wel even de uitkomst van een IQueryable.

[Gomez12]

Ik heb een broertje dood aan EF en Linq2SQL etc. vanwege 1 heel simpele reden...

Ik zie te veel voorbeelden waarin het niet gesnapt wordt en de sql-server simpelweg mishandeld wordt.

Dat varieert van combinaties van ORM + AutoMapper die ervoor zorgen dat het ophalen van 1 view-model voor een artikel 60 query's is (maar het is toch maar 1 EF call, yep alleen je Automapper definitie zorgt ervoor dat er nog 59 query's volgen)
Of rapportages/exports die 100.000+ records moeten produceren en je gewoon N+1 constructies richting de database ziet gaan met nog enkele query's per record ook.

En zoals iemand hier eerder al zei, 50ms+ maakt voor veel mensen niet echt uit bij 1 object, alleen een beetje web-page is opgebouwd uit 20+ objecten en dan zit je simpelweg al aan extra kosten aan 1 sec+ laadtijd.
En bij exports met 1000'en records wordt dat helemaal leuk.

[EfBe]

Voor de Dapper fetisjisten en anderen die ORMs gebruiken voor .NET ->

https://weblogs.asp.net/f...ults-and-the-fine-details

Dapper is helemaal niet zo snel als men denkt, er zijn andere microORMs die sneller zijn (en daarnaast typed query languages aanbieden, zodat je geen hard-coded tabelnamen etc. in je code hebt.). Zelfs full ORMs zijn sneller.

Dank voor de vriendelijke woorden omtrent ons werk aan LLBLGen Pro Het maakt niet uit wat je gebruikt, als je maar niet je eigen ORM gaat brouwen, dat is het geld van je klant niet waard: je bouwt ook niet je eigen ASP.NET achtig framework of webserver, want anderen kunnen dat beter, dus waarom wel data-access? Wat records uit een table trekken is niet zo lastig, object graphs terugschrijven, efficient entities laden in alle gevallen etc. is dat wel.

(Laat ik me verder afzijdig houden mbt mijn mening over de ORM 'Entity Framework', mijn mening is wellicht iewat gekleurd, ookal ondersteunt onze designer het heb ik er zodoende wel mee gewerkt )

[Sandor_Clegane]

Ik ben wel fan van PetaPoco, gewoon een extra class in je project en gaan met die banaan.

Type Providers zijn ook mooi. Maar het gewoon schrijven van een aantal methodes om SQL te laden via parameters werkt ook gewoon goed, het is wat code maar ja, je hebt er wel alle controle over.

SQL blijft nog wel een tijdje, mijn advies zou dan ook gewoon zijn: ga het niet uit de weg maar leer het gewoon, heb je nog jaren plezier van.

[sig69]

Sandor_Clegane schreef op zaterdag 3 maart 2018 @ 09:30:
Ik ben wel fan van PetaPoco, gewoon een extra class in je project en gaan met die banaan.

Type Providers zijn ook mooi. Maar het gewoon schrijven van een aantal methodes om SQL te laden via parameters werkt ook gewoon goed, het is wat code maar ja, je hebt er wel alle controle over.

SQL blijft nog wel een tijdje, mijn advies zou dan ook gewoon zijn: ga het niet uit de weg maar leer het gewoon, heb je nog jaren plezier van.

PetaPoco
Elk nieuw project bevat twee basisstappen:
-Entity Framework eruit
-PetaPoco erin

[Lethalis]

Tsja, ORM's... also called the Vietnam of computer science

Ik heb zelf voor mijn werk een simpele library geschreven die gebaseerd is op PetaPoco. Maar dan met veel uitgebreidere logging en error handling, zodat je ook ten allen tijde problemen ermee snel kunt opsporen.

Geen echte ORM, maar voldoende in 90% van de gevallen.

Met het Entity Framework ben ik ook nooit vriendjes geworden. Nhibernate heb ik gebruikt, maar ook weer spijt van gekregen. Performance technisch niet handig en even een veldje in de database toevoegen - zelfs met default waarde - en het onding gaat miepen.

Ik begrijp echt wel waarom, maar als je even snel wat moet fixen is het mega irritant.

Sowieso werk ik (helaas) veel aan een enorme Windows Forms applicatie. Zodra je daar Nhibernate gebruikt, is dat direct merkbaar in hoe snel (beter gezegd traag) de gegevens op het scherm komen etc.

Het moet er gewoon instant staan

Ik heb zelfs code die een DataSet vult, vervangen door code die direct gegevens uit een IDataReader leest om net die paar tientallen ms uit te sparen.

It adds up als je veel verschillende gegevens toont op verschillende controls etc.

In een web project heb je minder last van initialisatietijden, omdat normaal gesproken gebruikers niet hoeven te wachten op het opstarten van jouw web app. Hij zou immers al geladen moeten zijn.

Bij Windows Forms development krijg ik al boze klanten als het programma niet snel opstart Bedenk daar databases van meerdere gigabytes bij en honderden tabellen en een ORM wordt ineens een blok aan jouw been.

Ook al splits je de domeinen op etc. Ik heb het zo vaak geprobeerd.

Sowieso wordt onze workflow vaak bepaald door bestaande database schema's die niet altijd optimaal zijn voor ORM. En ben ik ook van oudsher gewend eerst de database te ontwerpen, daarna te coden.

Een tool moet mij daarbij assisteren, niet in de weg gaan zitten of zijn eigen voorkeuren proberen door te drukken. Bij EF ben ik eerst een tijdje bezig om allerlei naming conventions aan te passen etc.

Gek word ik ervan

Ik pluralize niet bijvoorbeeld. Ik vind dat niet netjes in een relationele database. Alles zou enkelvoudige namen moeten hebben. Dus Persoon ipv Personen of nog erger Persoons

Ach ik kan hier eeuwen over doorgaan.

Uiteindelijk schrijf ik liever wat extra data access code die het gewoon doet, tegen een stootje kan en lekker efficiënt is dan dat ik mij erger aan 1 of andere ORM tool die mij uiteindelijk vooral tijd kost en nog traag is ook.

PS
Ik heb zelf een IDbSession interface en implementatie gemaakt, om wel het UnitOfWork pattern te behouden (dat Nhibernate gebruikt) in mijn data access code. Sommige aspecten van ORM's zijn wel handig

[ Voor 4% gewijzigd door Lethalis op 04-03-2018 13:35 ]

[Tweezitsbank]

Ik ben geen fan van EF of andere ORMs (niet dat ik ze allemaal gezien heb natuurlijk). Veel van de nadelen zijn hier al genoemd; gebrek aan snelheid, ellende wanneer de database veranderd, ontbrekende features, geen of beperkte support in 3rd party libraries, een stijle learning curve... Wat ik heb gezien bij veel developers is het ontbreken van kennis omtrent SQL en specifieke features van database engines zoals SQL server, Oracle etc. Een select en update lukt meestal nog wel maar er is ook een hoop mogelijk met views of stored procedures. Ook dat zal vast niet heilig zijn maar in veel gevallen kom je daar prima mee weg en volstaat in de code een lichtgewicht setje classes die de communicatie met de database op zich neemt. Is mijn ervaring althans.

Er wordt weleens beweerd dat het nuttig is om eea via code te regelen, want stel je voor dat er een andere database engine moet komen. Dat kun je natuurlijk ook omdraaien, stop de logica in de database want stel je voor dat er een andere ontwikkelomgeving moet komen of dat je meerdere applicaties moet bouwen op 1 database. Dan is het toch wel prettig als je niet vast zit aan 1 of andere logge C# engine...

[EfBe]

Tweezitsbank schreef op zondag 4 maart 2018 @ 13:50:
Veel van de nadelen zijn hier al genoemd; gebrek aan snelheid, ellende wanneer de database veranderd, ontbrekende features, geen of beperkte support in 3rd party libraries, een stijle learning curve...

- Gebrek aan snelheid: behalve bij EF en NH die echt heel traag zijn, is de snelheid veelal niet het probleem. Ik geef je op een briefje dat de code van de gemiddelde programmeur die direct ADO gebruikt er niet eens bij in de buurt komt. Veel ORMs worden geschreven en onderhouden door mensen die dit al jaren doen en alle truuks en pitfalls wel kennen. De gemiddelde developer kent deze echt niet.
- Ellende wanneer de database verandert: Begrijp ik niet zo: je gebruikt toch ook een IDE en niet Notepad om je software te maken? Waarom gebruik je dan wel spartaanse tooling (lees: geen) wanneer die er gewoon is? Een veld toevoegen, een veld veranderen, tabel renamen etc. een goede designer pikt dat gewoon op. Kost mij nog geen 30 seconden en dan heb ik een up-to-date codebase. Los daarvan: een veld wijzigen/toevoegen in een database die gebruikt wordt met een micro 'ORM' (of handgeschreven troep) met hard-coded SQL: dat is pas ellende, want je krijgt de errors at runtime. Veel plezier met testen!
- ontbrekende features: veel ORMs zijn al jaren beschikbaar en erg volwassen (EF Core daargelaten ): ze doen alle basistaken al jaren. Alle edge cases zijn er wel uit. Handgeschreven data-access code heeft echt die features niet, want dat kost jou jaren om te bouwen, en los daarvan: je moet dat ook onderhouden.
- Geen of beperkte support in 3rd party libraries: geen idee wat je daarmee bedoelt...
- Stijle learning curve. Alles met functionaliteit heeft een learning curve, zoook een ORM. Maar als je denkt dat handgeschreven ADO code geen learning curve heeft dan heb je het mis. Sterker nog: het is 10 tegen 1 niet gedocumenteerd, de echte kennis zit bij 1 a 2 mensen en een vaak gehoord antwoord zal zijn "oh ja dat, ja dat moet ik nog eens fixen, je kunt het beter zo oplossen". Je kunt ook de manual van de ORM er op na slaan, examples bekijken etc. oh en vragen stellen aan hun support.

Het is tegenwoordig echt een domme actie om zelf data-access code te schrijven: wil je geen full ORM gebruiken? Gebruik dan een van de vele micro's, handmatig deze code schrijven is zoals "ik schrijf zelf wel even de web handler, want ik kan dat sneller/beter". Handgeschreven ADO code is veelal troep. Dit heeft een simpele reden: de mensen die dat schrijven zijn geen specialist op dat gebied. Ze gebruiken geen expression trees om materializers te compileren at runtime, ze weten niet hoe ze zonder alle memory op te vreten SQL moeten genereren, om maar wat te noemen. Anderen zijn dat wel. Waarom zou je dan op de stoel van een specialist gaan zitten om specialistisch werk te doen, waar jouw klant je niet eens voor betaalt! (want, het is overhead. Jouw klant betaalt je ook niet om een grid control te bouwen, die koop je).

Tuurlijk is het 'niet moeilijk' om wat generieke code te maken die een SQL string naar de database gooit, en die de terugkomende data in objects stopt. Met wat tijd krijg je dat ook nog wel redelijk snel (lees: je gebruikt niet meer reflection of cachet iig genoeg). Dat is niet de moeilijkheid. De moeilijkheid zit hem in het feit dat in jouw applicatie allerlei dingen met de database worden gedaan, nl. die nuttig zijn op die manier op die plek. Dat heeft wellicht specifieke queries nodig of specifieke resultset handling (ga maar eens een object graph mergen in memory, of nog leuker: in een object graph alle entities eruit halen die gesaved moeten worden. Of ga je dat met de hand doen? ) en de ontwikkelaar van de app wil niet dat ook nog eens zelf bouwen.

Dus de handgeschreven code met wat SQL moet dat ook allemaal aankunnen. Liefst efficient en snel, en vandaag nog. 10 tegen 1 dat het er niet inzit of gammel. Immers een full ORM die wel deze features heeft kost jaren om te maken (LLBLGen Pro kostte 15 jaar, EF full ook zo'n beetje, NHibernate ook), 1000-en gebruikers met feedback, 1000-en tests voor allerlei edge cases waar jij nu niet aan denkt maar waar je wellicht wel mee te maken krijgt en als je handgeschreven 'ORM' dan faalt kost dat jouw bedrijf geld. (Los van het feit dat het zelf schrijven ook geld kost, en het onderhouden helemaal. Geld wat je je kunt besparen door iets te gebruiken wat er al is en zich al bewezen heeft).

Dus zelf knoeien is dom. Sorry.

Wat ik heb gezien bij veel developers is het ontbreken van kennis omtrent SQL en specifieke features van database engines zoals SQL server, Oracle etc. Een select en update lukt meestal nog wel maar er is ook een hoop mogelijk met views of stored procedures. Ook dat zal vast niet heilig zijn maar in veel gevallen kom je daar prima mee weg en volstaat in de code een lichtgewicht setje classes die de communicatie met de database op zich neemt. Is mijn ervaring althans.

En hoe praten die met elkaar dan? Hoe ga jij betrouwbaar dat 'setje classes' op resultsets mappen van stored procedures? Dingen in stored procedures stoppen lost niet het probleem op dat je entities de transitie van set naar object graph moeten maken, het levert alleen een nieuwe API op en een boundary waarbij je als app ontwikkelaar veelal moeilijk overheen komt (als in: 'ik moet XYZ doen in de database' en dan moet je de DBA overtuigen dat 2 stored procedures moeten worden aangepast. Dat kan veelal niet (want wie weet ookalweer in welke software die procs worden gebruikt? Niemand, dus komt er een nieuwe proc bij) of moeizaam, of kost tijd etc. Begrijp me niet verkeerd, procs zijn een tool als alle andere en wanneer je data processing moet doen is het veelal efficienter dat te doen in een procedure zodat je niet de grote sets met data die je gaat processen naar de client moet halen, maar voor simpel DML werk, no way.

[ Voor 24% gewijzigd door EfBe op 05-03-2018 10:12 ]

[Sandor_Clegane]

Hmmm, dat iets door veel gebruikers wordt gebruikt maakt het niet automatisch beter moet ik zeggen.

Als je data in een DB wil stoppen heb je nu eenmaal te maken met een vertaling en de mooie kreet "object relational mismatch". Om dan maar net te doen dat deze niet bestaat door er een ORM overheen te zetten is volgens mij niet heel handig.

Dit doet me vooral denken aan netwerkprogrammeren en dan net doen of dat het netwerk niet bestaat zoals beschreven in: Wikipedia: Fallacies of distributed computing

Ieder zijn ding natuurlijk.

[Gomez12]

EfBe schreef op maandag 5 maart 2018 @ 09:56:
[...]
- Gebrek aan snelheid: behalve bij EF en NH die echt heel traag zijn, is de snelheid veelal niet het probleem. Ik geef je op een briefje dat de code van de gemiddelde programmeur die direct ADO gebruikt er niet eens bij in de buurt komt. Veel ORMs worden geschreven en onderhouden door mensen die dit al jaren doen en alle truuks en pitfalls wel kennen. De gemiddelde developer kent deze echt niet.

Dit ga je toch niet serieus menen? Een middle-of-the-road ORM gaat simpelweg traag werken in edge cases.

Een ORM is leuk voor CRUD-werk, maar bij iets verder gaan gaat een ORM simpelweg slechter presteren dan hand-coded dingen.

Dus zelf knoeien is dom. Sorry.

Jammer dat je niet kan inzien dat ORM's niet alles voor je alles gaan oplossen. Sterker nog ik ken bijna geen enkel serieus project waar een ORM 100% van de data-access doet, in bijna elk project zit wel een 5% handmatige sql vanwege performance en betrouwbaarheid redenen.

[Lethalis]

EfBe schreef op maandag 5 maart 2018 @ 09:56:
[...]
Gebrek aan snelheid: behalve bij EF en NH die echt heel traag zijn, is de snelheid veelal niet het probleem. Ik geef je op een briefje dat de code van de gemiddelde programmeur die direct ADO gebruikt er niet eens bij in de buurt komt. Veel ORMs worden geschreven en onderhouden door mensen die dit al jaren doen en alle truuks en pitfalls wel kennen. De gemiddelde developer kent deze echt niet.

Je beseft je dat je nu zelf wel de 2 belangrijkste en meestgebruikte ORM's die er zijn echt heel traag noemt?

Het is immers logisch dat mensen juist deze ORM's benchmarken ten opzichte van hun eigen implementaties. Juist omdat deze ORM's de voordelen bieden die je zelf noemt. Namelijk dat je makkelijk support kunt krijgen, veel edge cases ondersteund worden, enzovoorts.

Zodra je een andere ORM gebruikt die beter zou moeten zijn, maar vervolgens minder gebruikt wordt, loop je immers dezelfde risico's als bij een eigen implementatie.

[EfBe]

Lethalis schreef op maandag 5 maart 2018 @ 11:40:
[...]

Je beseft je dat je nu zelf wel de 2 belangrijkste en meestgebruikte ORM's die er zijn echt heel traag noemt?

Ja en dat heb ik zelf getest: https://weblogs.asp.net/f...ults-and-the-fine-details
Ze zijn echt *heel* traag.

Het is immers logisch dat mensen juist deze ORM's benchmarken ten opzichte van hun eigen implementaties. Juist omdat deze ORM's de voordelen bieden die je zelf noemt. Namelijk dat je makkelijk support kunt krijgen, veel edge cases ondersteund worden, enzovoorts.

Zodra je een andere ORM gebruikt die beter zou moeten zijn, maar vervolgens minder gebruikt wordt, loop je immers dezelfde risico's als bij een eigen implementatie.

EF en NH zijn niet de enige ORMs, er zijn veel betere: zowel in full als in micro. Ik draai vanaf 2002 mee in ORM land, werk sindsdien full time aan ORM middleware en entity modeling systems, en heb vele dingen zien gaan en komen. 'Minder gebruikt' wordt nu door jou weggezet als slechter, maar dat is natuurlijk helemaal niet zo. Op .NET zijn er legio ORMs geweest in de afgelopen 15 jaar, en vele zouden nu nog bestaan wanneer MS niet EF gratis had weggegeven en had gepromoot als 'de enige juiste oplossing'. Dat ze populair zijn is logisch: bv de 'default' templates in vs gebruiken allemaal EF. Je ziet dat met andere 'defaults' ook: er is bv zoiets als ServiceStack, wat veel minder wordt gebruikt dan ASP.NET webapi, maar is het slechter? niet echt. 9 van de 10 mensen heeft er nooit van gehoord want ze leven in de Microsoft bubble en als het niet uit Redmond komt zal het ook wel niet goed zijn.

Ik zou ook liever zien dat miljoenen mijn werk gingen gebruiken, maar dat is niet realistisch MS' marketing machine is domweg te groot (ja, EF is marketing, het team van 15+ mensen (!) kost meer dan een miljoen per jaar, zonder inkomen...). Is ook niet erg, velen vinden het prima werken en ieder z'n kicks. Wat al zou helpen is dat mensen meer kennis zouden krijgen van wat er nog meer beschikbaar is, bv in microORMs (de performance van Linq to DB bv is niet echt te evenaren, ookal gebruiken ze een smerige truuk die je wellicht de kop gaat kosten at runtime).

[ Voor 43% gewijzigd door EfBe op 05-03-2018 13:08 ]

[EfBe]

Gomez12 schreef op maandag 5 maart 2018 @ 10:49:
[...]
Dit ga je toch niet serieus menen? Een middle-of-the-road ORM gaat simpelweg traag werken in edge cases.

Hoezo? Denk je dat ORM developers na een aantal weken programmeren ophouden met dingen optimalizeren? Ik heb letterlijk alles bij elkaar meer dan 2 jaar full time besteed aan het optimizen van de pipeline. Alleen optimizing, dus geen ander werk. ORMs bieden verschillende query APIs (althans, de betere), dus je kunt altijd terugvallen op bv een lower level API wanneer bv Linq te beperkt is.

Dus waar jij vandaan haalt dat ze het niet trekken begrijp ik niet echt.

Een ORM is leuk voor CRUD-werk, maar bij iets verder gaan gaat een ORM simpelweg slechter presteren dan hand-coded dingen.

Wat zijn 'handcoded dingen'? Een handcoded SQL string? Of een stored proc? Of een partitioned view? Het maakt niet echt uit natuurlijk: wanneer je bv een rapport gaat genereren en je gaat 20 datastreams aggregaten op de client, dan zal dat niet performen, dan kun je beter de aggregates in de RDBMS doen, en indien je bv specifieke functies nodig hebt in de SQL Dialect die niet beschikbaar zijn in de ORM API, dan is handcoded SQL wellicht noodzakelijk. Maar die voer je toch gewoon uit via de ORM layer? Zodat je toch met je entities kunt werken? Wanneer je een proc nodig hebt (bv veel aggregates) en je resultset wil je gebruiken als objects, dan is de ORM toch gewoon de aangewezen middleware, of snap ik iets niet?

LLBLGen Pro's plain SQL api heeft bv paging features, zodat je je plain SQL queries niet hoeft aan te passen voor paging op de betreffende DB en mapt die ad-hoc op POCOs middels in-memory gegenereerde code at runtime. Maar je kunt ook andere APIs gebruiken met dezelfde types. Kleine dingetjes die de ORM layer aanbiedt die jij niet met de hand 'even maakt', laat staan optimized totdat er niets meer te halen valt.

[...]
Jammer dat je niet kan inzien dat ORM's niet alles voor je alles gaan oplossen. Sterker nog ik ken bijna geen enkel serieus project waar een ORM 100% van de data-access doet, in bijna elk project zit wel een 5% handmatige sql vanwege performance en betrouwbaarheid redenen.

Ik doelde niet op: Linq vs. handcoded SQL strings. Ik doelde op: <whatever ORM> vs. <zelfgeschreven data-access layer>. Er is geen reden om nog in 2018 zelf die data-access layer te gaan broddelen, sorry: er zijn legio volwassen libraries beschikbaar, met documentatie, met examples en battle-hardened optimized pipelines, dat ga je echt niet zelf doen: je eigen resultaat zal altijd slechter zijn, immers als het beter kon dan hadden de ORM devs dat al ingebouwd (op NHibernate na dan, die lui snappen er niets van, maar goed, dat is een ander verhaal )

[whoami]

Down schreef op vrijdag 2 maart 2018 @ 19:56:
[...]


We doen alles in principe met EF, tenzij performance echt een probleem is in welk geval we Dapper gebruiken.

Waarom val je in dat geval terug op Dapper als je toch al EF gebruikt ?
Via EF kan je ook perfect native SQL gaan uitvoeren en de results gaan mappen naar je entities.

[whoami]

Lethalis schreef op zondag 4 maart 2018 @ 13:27:

Met het Entity Framework ben ik ook nooit vriendjes geworden. Nhibernate heb ik gebruikt, maar ook weer spijt van gekregen. Performance technisch niet handig en even een veldje in de database toevoegen - zelfs met default waarde - en het onding gaat miepen.


Sowieso werk ik (helaas) veel aan een enorme Windows Forms applicatie. Zodra je daar Nhibernate gebruikt, is dat direct merkbaar in hoe snel (beter gezegd traag) de gegevens op het scherm komen etc.

NHibernate is op zich niet traag; als je het fout gebruikt dan kan het wel traag zijn, maar dat geldt voor iedere ORM tool

Ik heb zelf een IDbSession interface en implementatie gemaakt, om wel het UnitOfWork pattern te behouden (dat Nhibernate gebruikt) in mijn data access code. Sommige aspecten van ORM's zijn wel handig

De DbSession van EF implementeert ook gewoon het UoW pattern.

[Tweezitsbank]

EfBe schreef op maandag 5 maart 2018 @ 09:56:
Dus zelf knoeien is dom. Sorry.

Geeft niet, de discussie is wel interessant. Ik heb gemerkt dat er bijna nooit een middenweg is, mensen zweren bij een ORM of ze vinden het totaal waardeloos. En dat is wat mij betreft misschien nog wel het belangrijkste punt; als een groot deel van mijn team een ORM waardeloos vindt dan kun je alle gelijk van de wereld hebben maar dan ga ik het toch echt niet inzetten. Het gebrek aan motivatie om er mee te werken zal het project (en het resultaat) dan niet ten goede komen.

Inhoudelijk ga ik verder niet in op je punten als je het niet erg vindt (we gaan elkaar niet overtuigen das duidelijk), de mening echter dat in alle 100% van de gevallen een ORM een betere keus is (en altijd beter presteert) deel ik echter niet. Daar is een ORM te generiek voor en is er een te grote verscheidenheid aan toepassingen en applicaties. Buiten dat vind ik het voor mijn carriere als developer nuttiger om fatsoenlijke kennis van SQL te hebben in plaats dat ik het slechts als opslagruimte gebruik.

[EfBe]

whoami schreef op maandag 5 maart 2018 @ 13:55:
[...]
NHibernate is op zich niet traag; als je het fout gebruikt dan kan het wel traag zijn, maar dat geldt voor iedere ORM tool

Nou... het is echt niet rap, zie mn benchmarks eerder in deze thread. Dit is overigens niet zo raar. Ik heb het geprofiled omdat ik dacht "wtf... dit kan gewoon niet" maar ze hebben alles erg gedecentraliceerd in de codebase. Daar is op zich niets mis mee, maar calls zijn dan erg lang, en dat levert niet de snelste code op. De performance fragmenteert along the way en er is niet iets wat je zo kunt aanwijzen als "dit is de bottleneck".

Echt, het is niet anders

(EF6 is overigens hetzelfde: de code is zo ver gefragmenteerd dat je erg lange call chains krijgt. Profile het maar eens, echt niet normaal. )

Tweezitsbank schreef op maandag 5 maart 2018 @ 17:20:
Geeft niet, de discussie is wel interessant. Ik heb gemerkt dat er bijna nooit een middenweg is, mensen zweren bij een ORM of ze vinden het totaal waardeloos. En dat is wat mij betreft misschien nog wel het belangrijkste punt; als een groot deel van mijn team een ORM waardeloos vindt dan kun je alle gelijk van de wereld hebben maar dan ga ik het toch echt niet inzetten. Het gebrek aan motivatie om er mee te werken zal het project (en het resultaat) dan niet ten goede komen.

Dat is zeker waar. Een 'alles zit in stored procedures' shop krijg je daar echt niet van af. En dat hoeft natuurlijk ook niet, dat was ook niet mijn punt, sorry als dat niet goed overkwam. Mijn punt was dus niet: <gegenereerde SQL uit een ORM> vs <handgeschreven SQL> maar: <ORM middleware> vs. <handgeschreven middleware>. Als jij petapoco gebruikt, prima, dat is precies wat ik bedoel: jij gaat niet petapoco vervangen door een zelfgeschreven library, want die performt 10 tegen 1 slechter (niet dat je het niet kunt, je hebt waarschijnlijk de ervaring niet om het snel te krijgen )

Inhoudelijk ga ik verder niet in op je punten als je het niet erg vindt (we gaan elkaar niet overtuigen das duidelijk), de mening echter dat in alle 100% van de gevallen een ORM een betere keus is (en altijd beter presteert) deel ik echter niet. Daar is een ORM te generiek voor en is er een te grote verscheidenheid aan toepassingen en applicaties. Buiten dat vind ik het voor mijn carriere als developer nuttiger om fatsoenlijke kennis van SQL te hebben in plaats dat ik het slechts als opslagruimte gebruik.

Een ORM die jou hand-written (plain) SQL laat executeren is nog steeds een ORM, en een prima oplossing: immers de projection pipeline (resultset -> objects) bv zal efficient zijn, daar doelde ik op, niet: full ORM vs. microORM, want dat is inderdaad onzin.

Bijna alle full ORMs kunnen plain SQL executeren overigens, er is niet echt een noodzaak meer om naast je full ORM voor de CRUD functionaliteit ook een microORM te gebruiken voor 'de queries die de full ORM niet kan genereren of die te traag zijn'.

[ Voor 56% gewijzigd door EfBe op 05-03-2018 17:55 ]

[Mugwump]

Ik word eigenlijk in algemene zin steeds minder fan van ORM, met name ook omdat er steeds meer alternatieven voor SQL databases zijn en ORMs bij architecturale keuzes als CQRS / event sourcing / microservices / polyglot persistence eerder in de weg zitten dan dat ze helpen.

[Gomez12]

EfBe schreef op maandag 5 maart 2018 @ 17:48:
[...]
En dat hoeft natuurlijk ook niet, dat was ook niet mijn punt, sorry als dat niet goed overkwam. Mijn punt was dus niet: <gegenereerde SQL uit een ORM> vs <handgeschreven SQL> maar: <ORM middleware> vs. <handgeschreven middleware>.

Kan je dit verschil wellicht eens uitleggen want ik zie het niet echt volgens mij...
Helemaal niet omdat jij blijkbaar alles onder ORM middleware wil scharen.

Bij mijn prive-projectjes gebruik ik toch echt alleen maar dapper om handgeschreven sql uit te voeren. En dat komt 100% voort uit mijn zakelijke ervaringen waarin ORM's alleen maar bottlenecks qua SQL opleveren en daar (waar het een bottleneck is) ook vervangen worden door handgeschreven SQL.
Dapper kent wat makkelijke dynamic bindings etc waardoor ik het makkelijker vind dan een directe datareader, maar dat is het dan ook wel.

[...]
Bijna alle full ORMs kunnen plain SQL executeren overigens, er is niet echt een noodzaak meer om naast je full ORM voor de CRUD functionaliteit ook een microORM te gebruiken voor 'de queries die de full ORM niet kan genereren of die te traag zijn'.

Voor CRUD functionaliteit zijn juist ORM's een uitkomst, SQL is juist een uitkomst voor de dingen die niet CRUD zijn.
En plain SQL uitvoeren via een full blown ORM, tja laat ik het zo zeggen dat is mij nooit goed bevallen, dan zie je echt dramatische responsetijden terugkomen en die zitten alleen maar in ORM-functies die je op dat moment niet gebruikt en ook niet wilt gebruiken.

[whoami]

Mugwump schreef op maandag 5 maart 2018 @ 21:51:
Ik word eigenlijk in algemene zin steeds minder fan van ORM, met name ook omdat er steeds meer alternatieven voor SQL databases zijn en ORMs bij architecturale keuzes als CQRS / event sourcing / microservices / polyglot persistence eerder in de weg zitten dan dat ze helpen.

Vind ik wel wat vreemd, want ook bij CQRS & microservices heb je nog altijd een model waar je business logic in schuilt en van waar je zaken moet gaan persisteren.

Er zijn dan ook wel alternatieven voor SQL databases, maar ook die zijn niet in altijd zaligmakend.

[Mugwump]

whoami schreef op maandag 5 maart 2018 @ 22:58:
[...]

Vind ik wel wat vreemd, want ook bij CQRS & microservices heb je nog altijd een model waar je business logic in schuilt en van waar je zaken moet gaan persisteren.

Er zijn dan ook wel alternatieven voor SQL databases, maar ook die zijn niet in altijd zaligmakend.

CQRS en microservices lenen zich ook weer erg voor aggregate modelling. Een goed aggregate model leent zich vervolgens weer prima voor opslag in een documentstructuur.
Daarnaast was het punt ook juist dat opslag veel gefragmenteerder is. Je creëert opslag voor specifieke doeleinden. Hier een Redis cache, daar een search index, nog een document of een graph DB erbij, DWH voor reporting en ga zo maar door.
ORM doet wat het zegt, objecten naar een relationeel model mappen. Er zijn genoeg situaties waarin een relationeel model een prima oplossing is en daar is wat mij betreft helemaal niets mis met een keuze voor ORM.

[Ankona]

Tweezitsbank schreef op maandag 5 maart 2018 @ 17:20:
[...]


Geeft niet, de discussie is wel interessant. Ik heb gemerkt dat er bijna nooit een middenweg is, mensen zweren bij een ORM of ze vinden het totaal waardeloos. En dat is wat mij betreft misschien nog wel het belangrijkste punt; als een groot deel van mijn team een ORM waardeloos vindt dan kun je alle gelijk van de wereld hebben maar dan ga ik het toch echt niet inzetten. Het gebrek aan motivatie om er mee te werken zal het project (en het resultaat) dan niet ten goede komen.

Inhoudelijk ga ik verder niet in op je punten als je het niet erg vindt (we gaan elkaar niet overtuigen das duidelijk), de mening echter dat in alle 100% van de gevallen een ORM een betere keus is (en altijd beter presteert) deel ik echter niet. Daar is een ORM te generiek voor en is er een te grote verscheidenheid aan toepassingen en applicaties. Buiten dat vind ik het voor mijn carriere als developer nuttiger om fatsoenlijke kennis van SQL te hebben in plaats dat ik het slechts als opslagruimte gebruik.

Je merkt altijd weer dat je voor het hebben van een mening niet veel kennis van zaken nodig hebt. Veel mensen zijn nou eenmaal negatief over zaken die ze niet (goed) kennen.

Ik beheers EF niet goed en ben er ook niet echt fan van. Vandaar dat ik deze discussie ook aangeslingerd heb
ORM's in zijn algemeenheid vind ik prima. Dan kun je piepen over een overhead, performance etc. Maar een probleem waar je geen last van hebt is ook geen probleem. Meestal is de performance geen enkel issue. Veel belangrijker is dat je elegante goed leesbare en onderhoudbare code krijgt.

(en nog een laatste nood: Ik ken maar weinig zaken die zo leuk zijn als zelf je eigen ORM bouwen. Heerlijk abstract programmeren. Alleen.... je hebt ook een klant die je voor je gepruts moet laten betalen en bestaande ORM's zijn gratis beschikbaar en veel volwassener)

[Lethalis]

EfBe schreef op maandag 5 maart 2018 @ 12:44:
[...]

Ja en dat heb ik zelf getest: https://weblogs.asp.net/f...ults-and-the-fine-details
Ze zijn echt *heel* traag.

Tsja, dan klopt dat dus met mijn ervaring ermee en meteen ook de hoofdreden waarom ik ze niet gebruik.

EF en NH zijn niet de enige ORMs, er zijn veel betere: zowel in full als in micro. Ik draai vanaf 2002 mee in ORM land, werk sindsdien full time aan ORM middleware en entity modeling systems, en heb vele dingen zien gaan en komen. 'Minder gebruikt' wordt nu door jou weggezet als slechter, maar dat is natuurlijk helemaal niet zo.

"slechter" heeft bij mij alles te maken met het implementatierisico. Ik zeg niet dat ze in technisch opzicht slechter zijn Sterker nog, ik geloof zonder meer dat jouw product vele malen beter presteert dan een EF of NH.

Het probleem ontstaat alleen als ik een bedrijfskritische applicatie ga bouwen met jouw product en jij morgen door een bus wordt overreden. Dan zit ik ineens met een niet ondersteunde library in mijn systeem.

Dat Microsoft het voor elkaar heeft gekregen dat ik geen EF gebruik, is bijna knap te noemen. Ze hebben zoveel dingen verkeerd gedaan in technisch opzicht dat ik het niet gebruik ondanks alle product placement.

Ze zijn niet voor niets opnieuw begonnen met EF Core. Dat overigens best goed scoort in jouw benchmarks als ik het zo zie EF Core ga ik binnenkort dan ook eens evalueren.

[AtleX]

EfBe schreef op maandag 5 maart 2018 @ 12:44:
het team van 15+ mensen (!) kost meer dan een miljoen per jaar, zonder inkomen...

Semi-offtopic: Da's toch geen gek budget? Da's maar gemiddeld 66000-en-een-beetje aan kosten per devver. Qua salaris, na aftrek van allerlei verzekeringen en overhead als een werkplek en apparatuur en licenties, blijft daar zelfs best wel weinig van over.

[Gomez12]

Ankona schreef op dinsdag 6 maart 2018 @ 08:31:
[...]
ORM's in zijn algemeenheid vind ik prima. Dan kun je piepen over een overhead, performance etc. Maar een probleem waar je geen last van hebt is ook geen probleem. Meestal is de performance geen enkel issue. Veel belangrijker is dat je elegante goed leesbare en onderhoudbare code krijgt.

Wat ik altijd wel grappig vind bij ORM-discussies zijn de voorstanders die zeggen dat de performance geen issue is, alleen EF etc zijn wel traag/slecht etc.

Als performance geen issue is, dan is ook de performance van EF geen probleem. Alleen toch lijkt het geen probleem te zijn enkel op te gaan tot de magische grens van het geliefde ORM en alles daarboven is toch alsnog fout.

Terwijl het imho zo is dat performance er geen ruk toe doet bij een CRUD-applicatie.
En juist bij de echte massa-verwerkingen daar telt elke ms en wil je gewoon helemaal geen ORM ertussen hebben.
Terwijl de ORM-liefhebbers een beetje tussen de 2 uitersten heen zitten te spelen en te optimaliseren.

En elegante, goed leesbare en onderhoudbare code is soms gewoon niet mogelijk, sommige dingen zullen altijd een blackbox blijven.
Een geoptimaliseerde query van 400+ regels gaat niet opeens via een ORM leesbaarder worden. Dat blijft gewoon een sh*t-query en als daar iets in het db-model wijzigt dan gaat het ORM je performance niet magisch redden, het ORM kan zorgen dat je query op een makkelijk te onderhouden manier blijft werken, maar dan moet je niet verbaast opkijken als je query eerst 10 minuten duurde en nu 10 uur.

Begrijp me niet verkeerd, ik zeg niet dat een ORM overal overbodig is, alleen het is zeker niet overal nuttig.

AtleX schreef op dinsdag 6 maart 2018 @ 10:19:
[...]
Semi-offtopic: Da's toch geen gek budget? Da's maar gemiddeld 66000-en-een-beetje aan kosten per devver. Qua salaris, na aftrek van allerlei verzekeringen en overhead als een werkplek en apparatuur en licenties, blijft daar zelfs best wel weinig van over.

67.000 vind ik vrij weinig voor amerikaanse programmeurs.
En sowieso is het al foutief om het neer te zetten als zonder inkomen. MS gaat niet voor 1 product, zij gaan voor de gehele breedte en zolang ze over de gehele breedte winst maken kunnen ze dit soort ondersteunende dingen erbij doen die hun hele breedte sterker maken.

[Mugwump]

Ankona schreef op dinsdag 6 maart 2018 @ 08:31:
[...]

Je merkt altijd weer dat je voor het hebben van een mening niet veel kennis van zaken nodig hebt. Veel mensen zijn nou eenmaal negatief over zaken die ze niet (goed) kennen.

Ik beheers EF niet goed en ben er ook niet echt fan van. Vandaar dat ik deze discussie ook aangeslingerd heb
ORM's in zijn algemeenheid vind ik prima. Dan kun je piepen over een overhead, performance etc. Maar een probleem waar je geen last van hebt is ook geen probleem. Meestal is de performance geen enkel issue. Veel belangrijker is dat je elegante goed leesbare en onderhoudbare code krijgt.

(en nog een laatste nood: Ik ken maar weinig zaken die zo leuk zijn als zelf je eigen ORM bouwen. Heerlijk abstract programmeren. Alleen.... je hebt ook een klant die je voor je gepruts moet laten betalen en bestaande ORM's zijn gratis beschikbaar en veel volwassener)

Wat dat betreft vond ik dit stukje van Fowler altijd wel aardig. Met het gebruik van een standaard ORM is weinig mis als je een CRUD applicatie maakt op basis van een SQL database. ORM is gewoon best complex omdat het mappen van objecten naar relaties lang niet zo triviaal is als het misschien op het eerste gezicht lijkt. Je kunt dan dus OO of RR gaan werken om het probleem te omzeilen, maar als je dat niet doet, dan is ORM gewoon noodzakelijk.
En hoe leuk het ook is om zelf zaken te gaan bouwen die al 35 keer gebouwd zijn, vaak ga je het zelf niet beter doen dan bestaande frameworks en zakelijk gezien is dat dan ook vrijwel nooit een goed idee. Ik heb in de loop der jaren heel wat zelfgebouwde ellende op vele vlakken gezien van pogingen tot ORM of MVC frameworks, Excel / Pdf / whatever generatoren en ga zo maar door.

Gomez12 schreef op dinsdag 6 maart 2018 @ 10:49:
Terwijl het imho zo is dat performance er geen ruk toe doet bij een CRUD-applicatie.
En juist bij de echte massa-verwerkingen daar telt elke ms en wil je gewoon helemaal geen ORM ertussen hebben.
Terwijl de ORM-liefhebbers een beetje tussen de 2 uitersten heen zitten te spelen en te optimaliseren.

Nou ja, er zijn nog steeds relaties. Je moet wel iets weten van een ORM framework om te zorgen dat bepaalde operaties niet opeens duizenden queries gaan uitvoeren omdat gegevens uit een gerelateerde tabel in losse queries rij voor rij worden opgehaald of bijgewerkt
Performance is wel degelijk een overweging bij CRUD applicaties, maar dat gaat dan meer om wachttijd voor de gebruiker dan om througput.

En elegante, goed leesbare en onderhoudbare code is soms gewoon niet mogelijk, sommige dingen zullen altijd een blackbox blijven.
Een geoptimaliseerde query van 400+ regels gaat niet opeens via een ORM leesbaarder worden. Dat blijft gewoon een sh*t-query en als daar iets in het db-model wijzigt dan gaat het ORM je performance niet magisch redden, het ORM kan zorgen dat je query op een makkelijk te onderhouden manier blijft werken, maar dan moet je niet verbaast opkijken als je query eerst 10 minuten duurde en nu 10 uur.

Begrijp me niet verkeerd, ik zeg niet dat een ORM overal overbodig is, alleen het is zeker niet overal nuttig.

ORM frameworks bieden je vaak nog steeds wel de mogelijkheid om geoptimaliseerde queries te schrijven in SQL als je dat wilt. Een specifieke query van 400+ regels gaan herschrijven naar ORM is ook zeker niet zinvol. De relevante vraag is eerder waarom je een query van 400+ regels hebt en wat die precies doet. Wat ik vaak zie in systemen is dat men ene 'one-size fits all' relationele database heeft waarbij men zich in onmogelijke bochten moet wringen om zaken er met een nog enigszins redelijke performance uit te krijgen. Als je iets 'consumer facing' maakt dat bijvoorbeeld individuele klanten de mogelijkheid biedt om een factuur of een status van een bestelling op te vragen dan is dat een heel ander type informatievraag dan interne rapportagequeries over het totaal openstaande factuurbedrag of een in de tijd gesegmenteerde ontwikkeling van het ordervolume afgezet tegen een aantal andere variabelen. Als je het zelfde model hanteert ovor dat soort queries en dat zelfde model ook nog gebruikt voor de schrijfkant, dan wordt het überhaupt lastig om performancegaranties te gaan geven.

[Grijze Vos]

Ik ken de haat-liefde verhouding met EF heel goed. Ikzelf hik er al anderhaplf jaar tegenaan om eens een prototype te gaan bouwen gebaseerd op LLBLGen. Binnenkort eindelijk de tijd om het daadwerkelijk te doen. (Ben nu eindelijk officieel verklaard tot overhead, heb nu expliciet de opdracht om klantprojecten te mijden. )

Enige nadeel wat ik gezien heb aan LLBLGen is dat het in de 5 jaar dat ik het niet gebruikt heb het flink gegroeid is in feature set, zodanig dat ik bijna verdwaal. Maar goed, ook dat is een kwestie van erin duiken en wennen.

(@EfBe die vraag over twitter aan jou komt er binnenkort aan als DM hier op tweakers, da's denk ik het makkelijkst. Ben benieuwd of LLBLGen die specificieke use case aan kan, EF kan het iig niet.)

[EfBe]

Lethalis schreef op dinsdag 6 maart 2018 @ 08:39:
"slechter" heeft bij mij alles te maken met het implementatierisico. Ik zeg niet dat ze in technisch opzicht slechter zijn Sterker nog, ik geloof zonder meer dat jouw product vele malen beter presteert dan een EF of NH.

Het probleem ontstaat alleen als ik een bedrijfskritische applicatie ga bouwen met jouw product en jij morgen door een bus wordt overreden. Dan zit ik ineens met een niet ondersteunde library in mijn systeem.

Mja, los van het feit dat je de sourcecode gewoon ter beschikking hebt als klant, is dat altijd het risico. Microsoft heeft ook heel wat projects gekilled de afgelopen jaren, in dit kader zelfs een dicht bij huis: Linq to SQL. De enkele bug wordt daarin gefixed maar er is geen async, geen .net standard compliance etc., als je dat gebruikt dan zit je in een beperkte hoek waar de toekomst niet ligt.

Ze zijn niet voor niets opnieuw begonnen met EF Core. Dat overigens best goed scoort in jouw benchmarks als ik het zo zie EF Core ga ik binnenkort dan ook eens evalueren.

het scoort redelijk, maar ze zijn er nog niet Als ze meer features implementeren dan zien we wel verder. Let wel: hetzelfde team dat het niet voor elkaar kreeg EF6 efficient te krijgen zit hier ook aan de knoppen

AtleX schreef op dinsdag 6 maart 2018 @ 10:19:
[...]
Semi-offtopic: Da's toch geen gek budget? Da's maar gemiddeld 66000-en-een-beetje aan kosten per devver. Qua salaris, na aftrek van allerlei verzekeringen en overhead als een werkplek en apparatuur en licenties, blijft daar zelfs best wel weinig van over.

Dat bedrag was geextrapoleerd uit de team grootte, dus het feitelijke budget zal inderdaad veel hoger liggen, dat weet ik verder niet exact.

Grijze Vos schreef op dinsdag 6 maart 2018 @ 14:01:
Enige nadeel wat ik gezien heb aan LLBLGen is dat het in de 5 jaar dat ik het niet gebruikt heb het flink gegroeid is in feature set, zodanig dat ik bijna verdwaal. Maar goed, ook dat is een kwestie van erin duiken en wennen.

De oude APIs werken ook nog gewoon Ik hou van software dat wanneer je het gebruikt het ook blijft doen ookal wordt de featureset uitgebreid. Is niet altijd mogelijk in alle gevallen uiteraard, maar streef er wel naar. Zoals bv bij IBM DB2, code van 20 jaar geleden doet het nog steeds op de laatste versie. Niet omdat ze daarmee nieuwe klanten krijgen, maar wel dat ze weten dat bestaande klanten niet gefrustreerd raken omdat een feature is verdwenen die zij nu juist gebruikten.

[ Voor 33% gewijzigd door EfBe op 07-03-2018 09:55 ]

[Lethalis]

EfBe schreef op woensdag 7 maart 2018 @ 09:50:
[...]
Mja, los van het feit dat je de sourcecode gewoon ter beschikking hebt als klant, is dat altijd het risico. Microsoft heeft ook heel wat projects gekilled de afgelopen jaren, in dit kader zelfs een dicht bij huis: Linq to SQL. De enkele bug wordt daarin gefixed maar er is geen async, geen .net standard compliance etc., als je dat gebruikt dan zit je in een beperkte hoek waar de toekomst niet ligt.

Daar heb je ook helemaal gelijk in. Microsoft scoort wat mij betreft ook heel slecht in dat opzicht.

Ik ben ook blij dat nu zoveel open source is geworden, want hierdoor gaat het toch een eigen leven leiden als Microsoft weer eens verzaakt.

Voor de goede orde:

1. Linq to SQL was de eerste ORM die ik ooit heb gebruikt.
Imagine my surprise toen ze ermee stopten. Net nadat ik meerdere collega's had overtuigd het te gebruiken

2. Client GUI development
Dit is in .NET een wir war geworden van Windows Forms, WPF, UWP en weet ik wat. Het is jammer dat er geen duidelijk platform is dat de volledige aandacht krijgt. Ik snap dat Windows Forms verouderd is, maar ik heb ook niet het gevoel dat Microsoft nog veel aandacht aan WPF besteed.

3. We hebben hier op de zaak wat fans van Visual Basic .NET.
De ene dag komt Microsoft met een statement dat beide talen (C# en VB) first class talen zijn op het platform en evenveel aandacht zouden krijgen. De andere dag komt .NET Core uit met in eerste instantie alleen C# support. Tsja, probeer dan maar eens het team mee te krijgen.

4. .Net Core
Waar zal ik beginnen? De eerste versie was echt een prototype dat als 1.0 werd verkocht. Van "kijk ons hip zijn met project.json" naar "oeh, dat was toch niet zo'n handig idee". Van "dit is een geheel nieuw platform" naar "we moeten maar snel met een .NET standard komen anders gebruikt niemand het".

Anyways, vanaf versie 2.0 is het wel okee. Behalve dan dat ik sommige basale zaken nog steeds niet kan. PDF comes to mind. System.Drawing die waarschijnlijk nooit meer komt. Ik vind het prima om Skia Graphics te gebruiken of iets dergelijks, maar je wil iets van een "standaard". Iets waar een tool developer die bijvoorbeeld een goede PDF library gaat bouwen van denkt "laat ik dat ook gebruiken".

Even een factuurtje genereren in PDF, of bijvoorbeeld een verkoopkaart voor een auto (met netjes herschaalde thumbnails van diverse foto's, gegevens erbij, logo van de garage, etc) zou ik toch al gauw willen maken (we zitten in de automotive).

Dat is wat ons betreft "hello world". Op het full framework is dat allemaal geen probleem, zeker niet met behulp van DevExpress.

5. Project files
Ik moet hier ook even over ranten: why the fiep krijgt alleen .NET Core een mode waarin bestanden automatisch tot het project behoren? Waarom zit ik anno 2018 nog steeds in project file merge hell als ik met 5 mensen aan dezelfde Windows applicatie wil werken? (technisch gezien kan msbuild het prima, maar Visual Studio werkt niet mee)

Microsoft... argh

[AtleX]

Lethalis schreef op woensdag 7 maart 2018 @ 10:53:
5. Project files
Ik moet hier ook even over ranten: why the fiep krijgt alleen .NET Core een mode waarin bestanden automatisch tot het project behoren? Waarom zit ik anno 2018 nog steeds in project file merge hell als ik met 5 mensen aan dezelfde Windows applicatie wil werken? (technisch gezien kan msbuild het prima, maar Visual Studio werkt niet mee)

Dat kan wel. Zelf even je CSPROJ vervangen (of equivalent als je VB gebruikt) door het nieuwe formaat. Daarin zet je dan het TargetFramework op NET46 of NET47 of welke TFM je ook wilt en klaar is Lethalis. Je kan dan zelfs multi-targeting doen. Ik haal uit hetzelfde project in een enkele build een NET45 en NETCOREAPP/NETSTANDARD build. Dat is ook wel fijn, want meerdere target frameworks waren in het verleden gewoon ellende met meerdere projecten die elkaar weer importeerden. Dat was hel en verdoemenis.

[Mugwump]

Lethalis schreef op woensdag 7 maart 2018 @ 10:53:
[...]

Daar heb je ook helemaal gelijk in. Microsoft scoort wat mij betreft ook heel slecht in dat opzicht.

Ik ben ook blij dat nu zoveel open source is geworden, want hierdoor gaat het toch een eigen leven leiden als Microsoft weer eens verzaakt.

Ik verbaas me er sowieso over dat het in de .Netwereld een veel grotere zooi lijkt aan overlappende frameworks / technologieën en implementaties dan in de Javawereld (goed, niet zo'n bende als in de PHP of Javascript wereld, maar dat is dan ook echt een baggerzooi). Je zou zeggen dat juist één commerciële partij achter een technologie hebben zou helpen. Wat ze in de Java wereld vaak beter doen is een API spec definiëren (JPA / JMS / enzovoort) waarbij allerhande partijen weer een eigen implementatie kunnen maken, maar dan wel met een interface volgens de specificatie (en eventueel nog wat meer functionaliteit). Voordeel is dat je relatief eenvoudig van implementatie kan switchen. Men heeft het in .Net ook wel geprobeerd te introduceren, maar erg veel succes heeft de .Net Persistence API vooralsnog niet. Ik denk dat het wel enorm zou helpen om dergelijke standaarden meer te introduceren.

5. Project files
Ik moet hier ook even over ranten: why the fiep krijgt alleen .NET Core een mode waarin bestanden automatisch tot het project behoren? Waarom zit ik anno 2018 nog steeds in project file merge hell als ik met 5 mensen aan dezelfde Windows applicatie wil werken? (technisch gezien kan msbuild het prima, maar Visual Studio werkt niet mee)

Microsoft... argh

Dit is inderdaad één van m'n grootste ergernissen als ik weer eens een .Net klus doe. Ik zet een file op die locatie met een reden. Ik wil dat die gebruikt wordt. Als ik dat niet wil haal ik hem wel weg. Ik wil niet weer lopen klooien bij een Git rebase omdat de .csproj file weer moet worden gemerged.

[Sp@rkie]

Lethalis schreef op woensdag 7 maart 2018 @ 10:53:
[...]


Anyways, vanaf versie 2.0 is het wel okee. Behalve dan dat ik sommige basale zaken nog steeds niet kan. PDF comes to mind. System.Drawing die waarschijnlijk nooit meer komt. Ik vind het prima om Skia Graphics te gebruiken of iets dergelijks, maar je wil iets van een "standaard". Iets waar een tool developer die bijvoorbeeld een goede PDF library gaat bouwen van denkt "laat ik dat ook gebruiken".

Even een factuurtje genereren in PDF, of bijvoorbeeld een verkoopkaart voor een auto (met netjes herschaalde thumbnails van diverse foto's, gegevens erbij, logo van de garage, etc) zou ik toch al gauw willen maken (we zitten in de automotive).

Dat is wat ons betreft "hello world". Op het full framework is dat allemaal geen probleem, zeker niet met behulp van DevExpress.

hear hear. die CRUD tutorials met Angular en .NET Core WebApi EF Core heb ik ondertussen wel gezien..

[roy-t]

Ankona schreef op woensdag 28 februari 2018 @ 15:26:
[...]

Maar, je hebt gelijk als het gaat om modernere platform architecturen. Daar is de applicatie doorgaans de enige gebruiker en eigenaar van de database (met niet al te omvangrijke structuur) en kun je prima code first deze onderhouden.

Ik denk dat je hiermee de spijker op zijn kop slaat. EF werkt het beste als je eigenaar bent over de database. Als je dat niet bent moet je je in erg veel bochten wringen om alles juist te mappen. Ook kun je dan juiste de mooiste stukken (zoals migraties niet gebruiken)..


Ik vind zelf het werken met EF erg fijn, maar op dit moment zit ik aan de dark-side (java kant ) en gebruik ik mybatis. Want ik heb erg weinig invloed op hoe de database in elkaar zit. Die bestaat al een jaar of 15.

Over SQL vs Linq, tsja. Waar zul je het schrijven. Stiekem lijken de twee talen qua expressiviteit ontzettend op elkaar. (dat was ook het doel). Dus dat is puur wat je gewend bent denk ik.

[Sandor_Clegane]

MS is hun visie kwijt lijkt het, .Net Core had nooit gemoeten, net als WinRT/UWP. Als ze die energie nu eens hadden gestoken in het beter maken van de al beschikbare technologie ipv steeds de new shiny achterna te hobbelen.

Hetzelfde dat .Net ineens als NPM moet gaan werken, met al die debiele modules..... wat een drama.

[Ankona]

Sandor_Clegane schreef op woensdag 7 maart 2018 @ 18:35:
MS is hun visie kwijt lijkt het, .Net Core had nooit gemoeten, net als WinRT/UWP. Als ze die energie nu eens hadden gestoken in het beter maken van de al beschikbare technologie ipv steeds de new shiny achterna te hobbelen.

Hetzelfde dat .Net ineens als NPM moet gaan werken, met al die debiele modules..... wat een drama.

.net core is juist een investering om het bestaande beter te maken. In de afgelopen 15 jaar is het framework een beetje uit zijn voegen gegroeid en zijn er nieuwe inzichten gekomen. Vandaar dat ze dat maar eens aangepakt hebben.

Alleen al die tooling rond het framework.... buildserver, git client, test framework, issue tracking etc. Ze willen het allemaal bieden maar scoren nergens beter dan matig terwijl er zoveel veel betere alternatieven op de markt zijn. Dat is dus zonde van de energie die ze erin steken (en frustrerend als je weer eens bij een klant werkt die principieel vindt dat je alleen de tools van Microsoft mag gebruiken want dat is goed en die onbekende exoten zijn moeilijk/onbekend en vast niet beter. ....)

[Lethalis]

Sandor_Clegane schreef op woensdag 7 maart 2018 @ 18:35:
MS is hun visie kwijt lijkt het, .Net Core had nooit gemoeten, net als WinRT/UWP. Als ze die energie nu eens hadden gestoken in het beter maken van de al beschikbare technologie ipv steeds de new shiny achterna te hobbelen.

Hetzelfde dat .Net ineens als NPM moet gaan werken, met al die debiele modules..... wat een drama.

Het grote probleem waar Microsoft tegen aan begon te lopen is de groeiende populariteit van cloud diensten en de gigantische populariteit van Linux daarbij.

Ze begonnen steeds meer te merken dat nieuwe generatie programmeurs voor andere technieken en talen kiezen.

De hippe crowd met NodeJS, Python, Ruby, etc... Maar ook de meer behouden ontwikkelaars die steeds vaker Java kiezen.

Simpelweg omdat het beter op Linux draait en er hele communities met ditto aanbod aan gratis libraries bij zitten.

Microsoft heeft eigenlijk geen keus en moest 2 dingen doen:
1. De boel open sourcen.
2. .Net goed laten draaien op Linux.

Bij punt 2 ontstond echter een probleem, namelijk dat hele delen van .Net maar een dun schilletje om Win32 api's heen zijn.

Dus moest er een bijna volledige rewrite komen.

Tegelijkertijd is daar niet genoeg tijd voor, omdat andere technieken steeds populairder worden.

Mijn persoonlijke mening is dat wat knappe koppen bij marketing toen maar hebben bedacht het te hullen in een "optimized for the cloud" jasje om ons toch *iets* te geven, ook al is het niet af.

En dat we over een aantal jaar uiteindelijk gewoon 1 .Net hebben dat gebaseerd is op wat we nu kennen als .Net Core.

Ook SQL server komt naar Linux met een reden.

.Net Core is gewoon veel te vroeg als 1.0 aangeboden. Ik zie versie 2.0 eigenlijk als de eerste echte release van een product dat iig enigszins bruikbaar is geworden.

Met elke API die in .Net Standard erbij komt, groeit het ecosysteem, omdat je elke keer meer bestaande libraries van derden makkelijker kunt migreren.

PS
Ik gebruik thuis uitsluitend Linux. Door .Net Core 2.x en VS Code heb ik nu toch een - voor mij - handigere ontwikkelomgeving dan wanneer ik Python of Golang zou gebruiken.

C# blijft een fijne taal. Bij Golang werd ik gek van de error handling (ik miste try catch) en Python is mij te dynamisch (ik wil strong typing at compile time).

En Java. Tsja. Het heeft een super ecosysteem, maar zeker hobbymatig staat de hele houding van Oracle mij enorm tegen.

Dus .Net Core heeft wel zeker bestaansrecht. De manier waarop het geïntroduceerd werd is echter ronduit bagger.

[Mugwump]

Lethalis schreef op woensdag 7 maart 2018 @ 21:44:
[...]

Het grote probleem waar Microsoft tegen aan begon te lopen is de groeiende populariteit van cloud diensten en de gigantische populariteit van Linux daarbij.

En toch hebben ze in mijn ogen (als iemand die primair Java developer is) met Azure echt een uitstekend cloud platform neergezet dat echt heel hard en goed doorontwikkeld wordt, zeker als je bereid bent om voor een redelijke mate van vendor lock-in te gaan.

Ze begonnen steeds meer te merken dat nieuwe generatie programmeurs voor andere technieken en talen kiezen.

De hippe crowd met NodeJS, Python, Ruby, etc... Maar ook de meer behouden ontwikkelaars die steeds vaker Java kiezen.

Server side JavaScript heb ik echt nooit begrepen. Ja de leercurve van een .Net of Java is iets stijler, maar verder zie ik eigenlijk alleen maar nadelen.

C# blijft een fijne taal. Bij Golang werd ik gek van de error handling (ik miste try catch) en Python is mij te dynamisch (ik wil strong typing at compile time).

Go heb ik nog nooit gedaan. Python is vooral handig voor data science gerelateerde zaken in mijn ogen. Voor grote projecten wordt zo'n dynamisch taaltje mij veel te rommelig.

En Java. Tsja. Het heeft een super ecosysteem, maar zeker hobbymatig staat de hele houding van Oracle mij enorm tegen.

Welke houding precies? Ik zou wel willen dat Java wat minder conservatief zou zijn en net als C# gewoon eens pattern matching, nullable types, de Elvis operator, async / await, type inference voor lokale variabelen en meer van dat soort zaken sneller zou introduceren. Ik was onlangs echter nog op een conferentie met een paneldiscussie over de nieuwe, versnelde releasecyclus voor Java en daar waren toch heel veel mensen niet blij mee.

Op de JVM heb je ook nog wel weer talen als Scala of Kotlin die wel dat soort features hebben, maar net als bij F# is het lastig om daarvoor te kiezen. Het gros van de C# of Java developers lijkt al moeite genoeg te hebben om de basis van die talen te beheersen, laat staan een project te doen dat (deels) in meer functionele talen is geschreven.

[Sandor_Clegane]

Ankona schreef op woensdag 7 maart 2018 @ 21:25:
[...]

.net core is juist een investering om het bestaande beter te maken. In de afgelopen 15 jaar is het framework een beetje uit zijn voegen gegroeid en zijn er nieuwe inzichten gekomen. Vandaar dat ze dat maar eens aangepakt hebben.

Die inzichten kan ik niet helemaal rijmen, helemaal omdat het framework door de bank genomen niet heel groot is. Voor een gemiddeld project zit je toch weer aan zowat het hele framework vast omdat veel dingen "handig" zijn. Goed System.Drawing is misschien iets anders, maar ja, die krijg je er dan gewoon bij, die paar MB.


Ze hadden prima Mono kunnen verbeteren, dat draait zelfs op Android en Ios. Dus nee, die verbasterde C++ shims vind ik persoonlijk een stap terug. Helemaal als je stacktraces krijgt met Com interop meuk.

En het is echt weer 1 stap vooruit, 2 stappen terug lijkt het. Zo zonde.

Ik het helemaal eens met VS Code, maar Mono zou ook prima werken en dan kun je eigenlijk ook alles maken. Dan werkt XAML zelfs cross platform, die jongens van Xamarin hadden wel een visie.

Plus dat werkt allemaal met F#, en dat is bij MS een roodharig stiefkind lijkt.

[ Voor 12% gewijzigd door Sandor_Clegane op 07-03-2018 23:41 ]

[Lethalis]

Mugwump schreef op woensdag 7 maart 2018 @ 22:36:
[...]
Welke houding precies? Ik zou wel willen dat Java wat minder conservatief zou zijn en net als C# gewoon eens pattern matching, nullable types, de Elvis operator, async / await, type inference voor lokale variabelen en meer van dat soort zaken sneller zou introduceren. Ik was onlangs echter nog op een conferentie met een paneldiscussie over de nieuwe, versnelde releasecyclus voor Java en daar waren toch heel veel mensen niet blij mee.

Op de JVM heb je ook nog wel weer talen als Scala of Kotlin die wel dat soort features hebben, maar net als bij F# is het lastig om daarvoor te kiezen. Het gros van de C# of Java developers lijkt al moeite genoeg te hebben om de basis van die talen te beheersen, laat staan een project te doen dat (deels) in meer functionele talen is geschreven.

De "wij hebben meer advocaten dan programmeurs" houding. Java is ook niet echt open source.

Het is anno nu ook steeds lastiger te bepalen of je in conflict bent met Oracle's licentievoorwaarden. Vragen als "is dit een embedded device?" komen steeds vaker langs. Ik wil anno nu gewoon iets dat echt vrij te gebruiken is.

In technisch opzicht ben ik met je eens dat Java meer nieuwe features zou moeten krijgen. Ik vind Kotlin dan ook heel gaaf en een mooie praktische middenweg tussen Java en Scala.

Waar Java als platform echt veel beter dan .NET is, is het ecosysteem (overvloed aan handige en gratis libraries) en de tooling (Maven, Gradle, etc).

MSBuild haalt het daar niet bij. Zeker het gebruik van een DSL om een project te beschrijven (Gradle) vind ik geweldig. Je kan er zo ontzettend veel mee.

Toen Microsoft met project.json aan kwam zetten wist ik serieus niet of ik nou moest lachen of huilen. Ik zat echt vol ongeloof naar mijn scherm te turen. "Welke idioot heeft dit bedacht?"

Ik heb echt heel vaak zitten twijfelen om de Java kant op te gaan, omdat ik soms echt gefrustreerd raak als .NET ontwikkelaar. Maar goed, dan klaagt Oracle ineens weer zijn eigen klanten aan of ontslaan ze een groot deel van hun Java experts.

Mensen kunnen hier de strategie van Microsoft in twijfel trekken, maar die van Oracle vind ik veel gekker.

[Mugwump]

Lethalis schreef op donderdag 8 maart 2018 @ 07:40:
[...]

De "wij hebben meer advocaten dan programmeurs" houding. Java is ook niet echt open source.

Het is anno nu ook steeds lastiger te bepalen of je in conflict bent met Oracle's licentievoorwaarden.

Vragen als "is dit een embedded device?" komen steeds vaker langs.

Ik wil anno nu gewoon iets dat echt vrij te gebruiken is.

Je kunt ook nog de OpenJDK gebruiken natuurlijk.

In technisch opzicht ben ik met je eens dat Java meer nieuwe features zou moeten krijgen.

Ik vind Kotlin dan ook heel gaaf en een mooie praktische middenweg tussen Java en Scala.

Waar Java als platform echt veel beter dan .NET is, is het ecosysteem (overvloed aan handige en gratis libraries) en de tooling (Maven, Gradle, etc).

MSBuild haalt het daar niet bij. Zeker het gebruik van een DSL om een project te beschrijven (Gradle) vind ik geweldig. Je kan er zo ontzettend veel mee.

Klopt, MSBuild en dependency management in combinatie met de IDE (ook met Resharper) zijn wel mijn grootste ergernissen binnen de .NET wereld. Ik hoop dat Project Rider nog wat doorontwikkeld. Ik mis nu nog wel de nodige features met name op het Azurevlak waardoor het nog niet echt een alternatief is voor VS helaas. De combi VSTS / Azure werkt wel weer vrij mooi.

Toen Microsoft met project.json aan kwam zetten wist ik serieus niet of ik nou moest lachen of huilen. Ik zat echt vol ongeloof naar mijn scherm te turen. "Welke idioot heeft dit bedacht?"

Ik heb echt heel vaak zitten twijfelen om de Java kant op te gaan, omdat ik soms echt gefrustreerd raak als .NET ontwikkelaar.

Maar goed, dan klaagt Oracle ineens weer zijn eigen klanten aan of ontslaan ze een groot deel van hun Java experts.

Mensen kunnen hier de strategie van Microsoft in twijfel trekken, maar die van Oracle vind ik veel gekker.

Eerlijk gezegd heb je daar als Java developer geen last van. Oracle richt zich vooral op hun commerciële producten en partijen die echt de taal zelf 'hergebruiken' zoals Google met Android.

Maar goed, de .NET vs JVM discussie is wel wat off-topic hier.

[ Voor 1% gewijzigd door Mugwump op 08-03-2018 09:49 . Reden: kleine toevoeging ]

[whoami]

Lethalis schreef op donderdag 8 maart 2018 @ 07:40:
[...]
Ik heb echt heel vaak zitten twijfelen om de Java kant op te gaan, omdat ik soms echt gefrustreerd raak als .NET ontwikkelaar. Maar goed, dan klaagt Oracle ineens weer zijn eigen klanten aan of ontslaan ze een groot deel van hun Java experts.

Mensen kunnen hier de strategie van Microsoft in twijfel trekken, maar die van Oracle vind ik veel gekker.

Vreemd dat als je de strategie van Oracle gek vind, je soms overweegt om de Java kant op te gaam n:)

Zelf ben ik blij dat ik in de .NET hoek zit, als je ziet hoe snel C# evolueert tov Java.

[Mugwump]

whoami schreef op donderdag 8 maart 2018 @ 10:32:
[...]

Vreemd dat als je de strategie van Oracle gek vind, je soms overweegt om de Java kant op te gaam n:)

Zelf ben ik blij dat ik in de .NET hoek zit, als je ziet hoe snel C# evolueert tov Java.

Dat is een beetje een .Net kijk op de JVM. Oracle heeft niet de positie en rol m.b.t. de JVM die Microsoft heeft ten opzichte van .Net. Het Open Source karakte van de JVM leidt toch heel veel alternatieven. Alleen al voor de JVM zelf zijn er open source en commerciële alternatieven en er zijn echt een hele berg talen op de JVM die als alternatief voor Java gebruikt kunnen worden maar wel gewoon integreren met de hele berg aan libraries die er voor Java beschikbaar zijn. Kotlin kan bijvoorbeeld al gebruikt worden op Android als alternatief voor Java en Scala zie je veel in systemen waar je te maken hebt met een hoge mate van concurrency en bijvoorbeeld met Akka wordt gewerkt.
Op de .NET CLI zie je eigenlijk alleen de Microsoft talen en ports van andere al bestaande talen waarvan ik me afvraag in hoeverre ze serieus gebruikt worden.
Het .Net framework is vele malen omvangrijker dan de Java SE spec die bij Oracle ligt. De EE spec ligt inmiddels bij de Eclipse Foundation en wordt weer door verscheidene partijen van implementaties voorzien (Naast Oracle ook IBM, RedHat en Apache bijvoorbeeld).

Ik zie ook liever de evolutie van C# dan die van Java qua snelheid, maar de alternatieven zijn er gewoon. Het probleem is dat de gemiddelde developer al moeite genoeg heeft om C# of Java in de basis een beetje fatsoenlijk te beheersen, laat staan de wat recentere features. F# of Scala zijn dan heel eng.

[Sandor_Clegane]

Mugwump schreef op donderdag 8 maart 2018 @ 11:56:
F# of Scala zijn dan heel eng.

F# heeft fun als een keyword, hoe erg kan het zijn?

[Lethalis]

whoami schreef op donderdag 8 maart 2018 @ 10:32:
[...]

Vreemd dat als je de strategie van Oracle gek vind, je soms overweegt om de Java kant op te gaam n:)

Zelf ben ik blij dat ik in de .NET hoek zit, als je ziet hoe snel C# evolueert tov Java.

Tsja, omdat er een groot verschil zit tussen een strategie en de uitvoering daarvan.

C# als taal is echt prima en handiger dan Java als taal. De basis .Net SDK vind ik ook cleaner en logischer dan bij Java.

Maar als je daarna verder kijkt naar de beschikbaarheid van handige frameworks die goed ontworpen zijn, gratis libraries voor van alles en nog wat, handige build tools met plugins voor diverse IDE's, nieuwe JVM talen als Kotlin, Scala, etc.

Tsja, dan ziet Java er ineens anders uit. En veel daarvan is ook te danken aan de community en niet aan Oracle.

Wil .NET groeien, dan moet er dus in de open source community momentum ontstaan om er allerlei leuke dingen voor te bouwen.

Of dat gaat gebeuren is moeilijk te voorspellen. Het geeft iig moed dat partijen als JetBrains en RedHat het proberen te faciliteren.

En Microsoft heeft er goed aan gedaan het heel vrije licenties te geven met Apache en MIT.

Dus als de alternatieve IDE's, build tools en frameworks a la Nancy allemaal doorontwikkeld worden voor .Net Core / Standard dan komen we ergens.

Dan boeit het minder wat Microsoft van ASP.Net heeft gebakken. Net zoals dat de meeste Java devs een open source framework gebruiken als Spring of Play of <vul maar in>.

Het kan nog alle kanten op. Maar voorlopig loopt Java jaren voor op dit gebied.

En tegen die tijd hebben we waarschijnlijk ook handigere ORM's erbij gekregen