NReco.Data
Entity Framework 6
Our great sponsors
NReco.Data | Entity Framework 6 | |
---|---|---|
1 | 2 | |
181 | 1,407 | |
0.6% | 0.3% | |
4.3 | 8.3 | |
3 months ago | 8 days ago | |
C# | C# | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
NReco.Data
-
For new projects, do you prefer EF, ADO, Dapper or something else?
We use https://github.com/nreco/data in our products, similar to Dapper but with built-in SQL generation for CRUD-queries (it is very easy to compose filters in run-time) + hand-written SQL may be concentrated in one place (app-level 'dataviews').
Entity Framework 6
-
ASP.NET Performance optimization question
Additionally, an individual context will also cache the actual sql being performed and their docs go over the caching it does here regarding that.
-
Ask HN: What tangible benefits did you get from spending time on HN?
Every so often, posts from Bruce Dawson's blog get posted here - one such post was about using Event Tracing for Windows to diagnose an issue with an NTFS lock being held causing 63 cores to idle while 1 does all the work.
https://randomascii.wordpress.com/2019/10/20/63-cores-blocke...
A few months later, some other people in my team were struggling to diagnose an issue in production where a legacy webapp was struggling to scale up and fully use all 64 cores of the server we needed it to run on. I stepped in to help and remembered that post I'd seen on HN. We used ETW (through Windows Performance Recorder and Windows Performance Analyzer) to profile our app and I looked into the Wait Analysis. Turns out that Entity Framework 6 uses a ReaderWriterLockSlim to guard a cache, and that particular lock performs extremely poorly under heavy contention. Heavy in our case meant that for a single page build of one of this app's "hot path" pages, this lock would be taken a few hundred thousand times. We weren't the first to discover this:
https://github.com/dotnet/ef6/issues/1500
What some other people in my team were struggling with for about two weeks was resolved in a single day thanks to me goofing off and reading HN. (We ultimately used a fork of EF6 that didn't suffer from this issue to solve our problem)
What are some alternatives?
Dapper - Dapper - a simple object mapper for .Net [Moved to: https://github.com/DapperLib/Dapper]
PetaPoco - Official PetaPoco, A tiny ORM-ish thing for your POCO's
Dapper.FastCRUD - fast & light .NET ORM for strongly typed people
NPoco - Simple microORM that maps the results of a query onto a POCO object. Project based on Schotime's branch of PetaPoco
NHibernate - NHibernate Object Relational Mapper
SmartSql - SmartSql = MyBatis in C# + .NET Core+ Cache(Memory | Redis) + R/W Splitting + PropertyChangedTrack +Dynamic Repository + InvokeSync + Diagnostics
ServiceStack.OrmLite - Fast, Simple, Typed ORM for .NET
FluentMigrator - Fluent migrations framework for .NET
MockQueryable - Mocking Entity Framework Core operations such ToListAsync, FirstOrDefaultAsync etc
Dapper Extensions - Dapper Extensions is a small library that complements Dapper by adding basic CRUD operations (Get, Insert, Update, Delete) for your POCOs. For more advanced querying scenarios, Dapper Extensions provides a predicate system. The goal of this library is to keep your POCOs pure by not requiring any attributes or base class inheritance.
LINQ to DB - Linq to database provider.