• Save
Entity Framework and Domain Driven Design
Upcoming SlideShare
Loading in...5
×
 

Entity Framework and Domain Driven Design

on

  • 1,023 views

Given at Oredev 2013 (Nov 2013 in Malmo Sweden). This presentaiton is about the intersection of Entity Framework (EF ) and Domain Driven Design (DDD) and gives pointers about *not* worrying about EF ...

Given at Oredev 2013 (Nov 2013 in Malmo Sweden). This presentaiton is about the intersection of Entity Framework (EF ) and Domain Driven Design (DDD) and gives pointers about *not* worrying about EF when implementing your domain in code and what you can expect when it's time to implement the persistence layer. There is a video of me giving this presentation on Vimeo at http://vimeo.com/78893724

Statistics

Views

Total Views
1,023
Views on SlideShare
1,023
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Focus on repo on this slide, then use code samples to quickly show difference between code that uses context directly and code that uses a repository, also show unit of work encapsulating a transaction possibly sharing reposPoints to make about demo ware…controller has direct access to /dependeny on EF. Need to know ins and outs of EF, linq to EF etc to get and update the data you want. Changes to data access logic may have direct impact on controller code which then needs to be modified. That may impact the UI code. That’s just the beginning of the problems.

Entity Framework and Domain Driven Design Entity Framework and Domain Driven Design Presentation Transcript

  • @JulieLerman Øredev 2013 ThankyouMarkRothko Entity Framework Domain Driven Design
  • My Two Worlds
  • D is for Domain not Persistence
  • Database Inspired
  • UI LINQ Logic Database
  • Separation of Concerns Maintainable Adaptable Testable Extensible Organized
  • *** Driven Development Business ProblemSoftware Solution Code OCD
  • Business/Domain Layer Repository/Unit of Work Infrastructure/Data Model ORM/Entity Framework Database UI Service Layer LINQ Tests Tests
  • Domain Models Services Data Layer Repositories Domain Events Infrastructure
  • Considering the Domain Customers Sales Orders Products Payments Shipments Shippers Promotions SalesPeople Employees SalaryHistory Returns Typical Model/DbContext
  • DDD Bounded Contexts for Application Subsystems Customer Service Order Taking Billing Returns Marketing Human Resources Shipping
  • Focused DbContexts Products Promotions Customers SalesPeople Employees SalaryHistory Returns Orders Customers Payments Orders Customers Customer Service Orders Customers Billing Returns Marketing Human Resources Shipments Shippers Shipping Orders DB DB Order Taking
  • Focused DbContexts Products Promotions SalesPeople Employees SalaryHistory Returns Orders Payments Orders Customer Service Orders Billing Returns Marketing Human Resources Shipments Shippers Shipping Orders Customers Customers Customers Customers Order Taking DB DB
  • Rich Domain Models Anemic Domain Models
  • PRIVATE SETTERS PUBLIC METHODS
  • DDD is for solving Complex Problems. Quite often, CRUD is enough
  • Value Objects
  • EF & DDD Value Objects EF Complex Types • No Identity Key • Property of Entity/other Complex Type • Maps to columns of parent entity/entities DDD Value Object • No Identity Key • Immutable • Equality compares all values • No Side-Effects
  • Do You Need a Persistence Model? Entity Framework/Queries/Commands Domain Model Persistence Model Payments Invoices Customers DB Mappings, DB concerns, Follow EF rules Domain Model Payments Credit Invoice Payee Payments Credit Invoice Payee Credits
  • Many variations… One repo per type? Read repos? Write repos? One repo per object graph? One repo per context ?
  • Testing with EF in the Mix • EF only or Database? • Using database: DropCreateDatabaseAlways Integration/ Tests • No EF involved: Inconsequential • EF in the way: Abstraction/Interfaces Unit Tests
  • Replace EF Behavior in Tests Mocking Frameworks • Learning Curve • Magic • DbSets are not always supported Roll Your Own Fakes • Learning Curve • More coding effort • Educational EF6 More Easily Supports Mocks • DbSet has new features • Chose not to enhance IDbSet to match • Instead, DbSet is more mockable • Protected constructor has no ties to DbContext
  • DDD += EF • Focus on Domain • Map to persistence later • EF can resolve most DDD patterns • Some tweaks may be required • Consider separate persistence model in more complex scenarios
  • Coming Soon Domain Driven Design course
  • Resources • Coding for Domain-Driven Design: Tips for Data-Focused Devs Part 1-3 MSDN Mag Data Points Column August 2013, Sept 2013, October 2013 • Pluralsight On-Demand Training: pluralsight.com • MSDN Developer Center: msdn.com/data/ef • EF Team: blogs.msdn.com/adonet • LearnEntityFramework.com • Programming Entity Framework: DbContext • by Julie Lerman and Rowan Miller, O’Reilly Media, Feb 22 2012 • Domain Driven Design By Eric Evans, Addison-Wesley, 2004 • Implementing Domain Driven Design, A-W, Vaughn Vernon, 2013 • domaindrivendesign.org
  • consultant/mentor Microsoft MVP, INETA Speaker, ASPInsider, MCP, VTdotNET Leader contact jlerman@theDataFarm.com www.thedatafarm.com blog theDataFarm.com/blog twitter @julielerman book web site LearnEntityFramework.com Contact Info (40% off at O’Reilly booth)
  • Mark Rothko 1903 - 1970