Entity Framework Course with the SVILUPPATORE MIGLIORE method
Master the reference ORM in the .NET ecosystem. Performant queries, controlled migrations and data architectures that hold up in production.
1-on-1 Mentor On YOUR code Measurable results
Your team uses Entity Framework. But do they use it well?
In our experience, the answer is almost always no. Most .NET teams use EF Core as an automatic SQL query generator, without understanding what happens under the hood. The result: N+1 queries, wrong loading strategies, migrations that break production and performance that degrades as data grows.
Entity Framework Core is a very powerful tool, if you know how to use it. But used badly it is a time bomb in your code.
If you are a CTO who sees database performance degrade sprint after sprint, a team leader who wants to introduce solid patterns for data access, or a senior developer who wants to master EF Core at an advanced level, this path is designed for you.
What you learn: the complete programme
2 phases, 8 modules of intensive training on YOUR code.
2 phases, 8 modules of intensive training on YOUR code.
PHASE 1: EF Core Foundations (Weeks 1-4)
- 1
How EF Core sees your database, and how to make sure it does not get it wrong
The DbContext is the contract between your code and the database. Configuring it halfway, with implicit conventions and mappings that seem to work, is the quickest way to end up in trouble. After 6 months of development, implicit mapping produces a schema that does not match the domain model and unmanageable migrations that nobody wants to touch. In this module you build explicit, readable and maintainable configuration from day one.
Programma
- DbContext lifecycleScoping in ASP.NET Core, pooling for performance, concurrency and why not sharing it between threads is a rule, not a suggestion
- Fluent API instead of Data AnnotationsHow to describe complex entities with owned types, value objects and table splitting without polluting domain classes
- IEntityTypeConfigurationHow to separate each entity's mapping into a dedicated class instead of having a 500-line OnModelCreating
- TPH, TPT, TPC inheritance strategiesWhat they actually generate at SQL level, which to choose and what performance problems they hide
- Shadow properties and backing fieldsHow to map database columns to internal properties the domain does not expose externally
- Global query filtersHow to apply multi-tenancy and soft delete filters in one place, without ever forgetting them in any query again
Risultato
The database is correctly mapped from day one. The DbContext is clean, every entity is explicitly configured and future migrations hold no surprises.
- 2
Why the database is slow (and it is not the server's fault)
The scene is always the same: the application is slow, the DBA says the queries are fine, the developers say the code is fine. In between is EF Core generating SQL that nobody has ever read, often turning a simple page into dozens of unnecessary queries. Here you enable query logging, read the generated SQL and resolve the issue at the root.
Programma
- Query loggingHow to enable it and read the generated SQL, the first thing to do when EF is slow and that almost nobody actually does
- Projections with SelectThe difference between loading 50 columns and 3, because EF loads everything if you do not explicitly stop it
- IQueryable vs IEnumerableThe line that decides whether filtering happens in the database or after loading 200,000 records into memory
- Split queriesWhen splitting a complex query with many Includes gains seconds and when it actually makes things worse
- Compiled queriesPrecompile the query once, execute it thousands of times without parsing overhead for high-frequency critical paths
- Query tagsAdd a readable label to the generated SQL to find it immediately in production logs instead of guessing which query is causing the problem
Risultato
When a slow page becomes fast, you know exactly why. You read EF-generated SQL as if you had written it by hand. No mystery under the hood.
- 3
The N+1 problem: the silent killer that slows applications without being seen
It works in development. It works in staging. But in production, with real data, the application makes 500 queries instead of 1. The N+1 problem is the most common and most difficult performance bug to spot in EF Core codebases, and in most cases nobody knows until the first real load. Here you learn to recognise, diagnose and resolve it definitively.
Programma
- Include and ThenIncludeHow to tell EF to load the necessary relationships in a single query instead of one per entity found
- Explicit loadingHow to load relationships on-demand only when needed, for cases where eager loading would be wasteful
- Lazy loadingHow it works, why in the vast majority of enterprise cases it is a trap and when it makes sense to enable it
- AsSplitQuery vs single queryThe concrete performance trade-offs, less duplicated data versus more database round-trips
- Interceptors for monitoringHow to automatically log all queries exceeding a time threshold in production
- MiniProfiler integrationHow to visualise in real time how many queries each page of your application is making
Risultato
Zero hidden queries silently killing performance. Every data loading operation is intentional, optimised and verified.
- 4
Migrations that never break production
EF Core migrations are the right tool for versioning the database. But in a team with multiple developers and parallel branches they quickly become a source of conflicts. An emergency rollback on a Saturday night due to a badly managed migration is the kind of experience that permanently changes how a team approaches the database. This module builds the migration strategy that eliminates this category of problems.
Programma
- Team migration strategyHow to avoid conflicts when two developers modify the model in parallel on different branches
- Data seedingHasData for stable lookup data versus custom code seeding for data dependent on business logic
- Migration bundlesHow to package migrations into an executable for automated deployment without relying on EF CLI on the server
- Rollback strategy and idempotent migrationsHow to build migrations you can run twice without damage, essential for automated deployments
- Multiple environmentsHow to manage different migrations for development, staging and production without a single script that works badly everywhere
- Schema comparison and database driftHow to detect when the production database has drifted from the EF model, before it becomes a problem
Risultato
Database deployment is a boring event, not a tense moment. Migrations are applied automatically, conflicts are detected immediately and rollback is always possible.
PHASE 2: Architecture and Advanced Scenarios (Weeks 5-8)
- 5
Repository pattern yes or no? The definitive answer (with code to prove it)
Few topics divide .NET developers as much as the Repository pattern with EF Core. Some say it is needed for abstraction and testing. Others say DbContext is already a Unit of Work. The debate is not resolved with opinions: it is resolved by analysing your specific context with concrete data and measurable consequences. Here you get a definitive answer with code, real scenarios and solid technical reasoning.
Programma
- Repository patternWhen it adds real value, applications with multiple data sources and testing without a database, and when it is just a useless wrapper
- Unit of Work with DbContextHow EF Core already implements this pattern and why duplicating it introduces subtle lifetime management bugs
- Specification patternHow to make queries reusable and composable without exposing IQueryable outside the data layer
- CQRS with EF CoreRead model optimised with projections and queries separated from the write model that uses the change tracker
- Domain events with MediatRHow to publish domain events after the transaction has been committed, without coupling the domain to infrastructure
- Multi-DbContext for bounded contextsHow to separate modules with different DbContexts pointing to the same or separate databases
Risultato
Clear and testable data architecture, without unnecessary layers. Every architectural decision is motivated by a concrete requirement, not a habit-driven pattern.
- 6
The bug that destroys user data: concurrency managed without fear
Two users open the same record, modify it, save. Who wins? Who loses? Who does not even know they have lost their changes? Concurrency is the hardest bug to reproduce in development and the most costly in production, because it only surfaces with real users and real data. Here you build the concurrency management that protects user data in any scenario.
Programma
- Optimistic concurrency with RowVersionHow to make EF Core throw an exception instead of silently overwriting another user's data
- Conflict resolutionConsciously choosing between client wins, server wins or showing the difference to the user, instead of letting it happen by accident
- Transaction scope and isolation levelsThe difference between Serializable and Read Committed and why choosing wrongly causes deadlocks or dirty reads
- Outbox patternHow to guarantee that an event is published if and only if the transaction succeeded, without lost or duplicate messages
- IdempotencyHow to build operations you can call 10 times with the same effect as 1, essential for automatic retries and distributed queues
- Distributed transactionsWhy to almost always avoid them and which alternative patterns to use to maintain consistency
Risultato
You can look a CTO in the eye and say: user data is never lost, even with 500 concurrent users. And you have the codebase to prove it.
- 7
How to test code that touches the database without going mad
Testing code that talks to a database is the point where most teams give up and leave the data layer untested. But testing without a real database leads to tests that do not detect real bugs: the difference between the InMemory provider and SQL Server in production is enormous. Here you find the balance with tools that detect real bugs without slowing the suite.
Programma
- InMemory providerWhat it really tests and what it does NOT test, because trusting it too much leads to surprises with real SQL
- SQLite in-memoryHow to get closer to SQL Server behaviour with minimal overhead and where it still differs
- TestContainersStart a real SQL Server or PostgreSQL in Docker for integration tests and destroy the container at the end without manual cleanup
- Test data buildersHow to build complex test objects in a readable way without factory methods with 20 parameters
- Integration tests with WebApplicationFactoryTest the entire application pipeline including the real database connection in a test that reads in 10 lines
- Performance tests for critical queriesHow to automatically measure that important queries do not degrade between releases
Risultato
The data layer is tested with tools that detect real bugs. Database regressions are found in tests, not in production at midnight.
- 8
When EF Core is not enough: how to work around it without losing its advantages
EF Core is the right tool for 90% of cases. For the remaining 10%, bulk operations, complex queries, legacy stored procedures, NoSQL databases, different tools are needed. Knowing when to step outside EF Core and how to do so without dismantling the architecture is the skill that separates senior developers from those who depend on a single tool. Here you learn to use all available tools at the right moment.
Programma
- FromSql, SqlQuery and ExecuteSqlHow to execute direct SQL while keeping the change tracker active and type safety on results
- Stored procedures and database functionsHow to call them in a type-safe way and integrate them with the rest of the data layer
- Bulk insert and update with EFCore.BulkExtensionsHow to insert 10,000 records in 2 seconds instead of 4 minutes with SaveChanges
- Interceptors for audit trail and automatic soft deleteHow to add cross-cutting behaviours to the data layer without touching application code
- Change tracker diagnostics and optimisationHow to understand what EF is tracking, when to use AsNoTracking and how to reduce tracking overhead
- Cosmos DB providerHow to use EF Core with NoSQL databases while keeping the same programming model as relational
Risultato
You master all the tools for any data access scenario. You are never blocked by an EF Core limitation: you know exactly how to work around it and when the right moment is.
The method: Architecture of Progressive Mastery
We start from your existing EF Core code. We analyse the slowest queries, identify anti-patterns and build best practices together for your specific context.
This is not a theoretical course on EF Core. It is a path to transform the way your team manages data, with measurable results in performance and maintainability.
Who this path is for
Developer who wants to master EF Core
You use Entity Framework but know there is more under the hood. You want to understand the generated queries, optimise performance and use the advanced features that make the difference.
Team with database performance problems
Queries are slow, the database is a bottleneck and nobody knows exactly why. You want an expert to analyse your use of EF Core and guide you towards the solution.
CTO who wants an enterprise-grade data layer
The data layer is the heart of your applications. You want consolidated best practices, safe migrations and a team that knows how to handle data complexity.
Who is Matteo Migliore
What professionals who have followed the path say
Those who study with Matteo have the opportunity to access a very meaningful and concrete experience, entering the world of software development with a reliable and competent guide.
His training is a real opportunity for young people who want to pursue a career as a software architect.
I definitely recommend him, especially for the professionalism he has always shown and his ability to explain numerous topics that are normally not covered in these types of courses.
The WPF course I had the fortune to take with Matteo Migliore literally opened up an incredible world for me, allowing me to acquire all the techniques that will enable me to tackle increasingly important projects.
I definitely recommend Matteo for the technical content and the experience he brings; the training journey was also rich in anecdotes where he shared his experiences going all the way back to when he was a child.
I recommend Matteo's course especially to beginners and anyone who needs to learn how to structure an application, because this way you can start already with a correctly built architecture.
One difference I notice compared to other courses is a great passion for training, understood in a very broad sense. It is a mission for them, and beyond the specific WPF course topics, I always find tips and suggestions on cross-cutting subjects like design, software control and testing — which gives me something extra in my overall development approach.
Often there is little time and great difficulty managing on your own the issues you encounter daily, and if you tend to limit yourself to your own knowledge you end up stuck in your own mistakes.
Going back over things I had studied at university, explained step by step in a new language I had not studied before, was extremely useful.
I turned to our consultant, Matteo Migliore, to enter this new world.
Thanks to the course I learned a programming approach built in a much more sensible way than what I was doing before.
I recommend Matteo because he is a very competent person who loves his work and cares about helping others, making them more productive and more capable of mastering technology.
What I liked most was the new management of the project structure: separating the UI from the design layer, and in particular not writing code directly in the UI but structuring it properly.
Matteo doesn't simply read from a pre-prepared script but is able to go deeper into syntactic elements and design patterns, perfectly following the needs of whoever is learning.
Investment and path
Paths are structured to measure based on the number of participants, duration and complexity of the project.
Fill in the form to receive the complete programme and a personalised quote based on your specific needs.
Individual Path
1 participant, personalised mentoring
- 8 complete modules
- Live bi-weekly 1-on-1 sessions
- 12-month platform access
- Continuous chat support
Team Path
2-3 participants, department transformation
- 8 complete modules
- Work on company codebase
- Analysis of real project queries
- 12-month platform access for everyone
Intensive Workshop
1-2 days on specific topics
- Focus on performance or migrations
- Up to 5 participants
- Complete teaching material
- Follow-up session at 30 days
Ready to master Entity Framework Core?
Fill in the form and receive all the information about the EF Core path. We will analyse your scenario and the best path for you or your team.
Free analysis We assess your current data layer and the main issues
Talk to a mentor Not with a salesperson, but with a real expert who will guide you
Practical guidance Receive useful guidance even if you decide not to continue