consultant/mentor microsoft mvp, ineta speaker, aspinsider, mcp, vtdotnet leadercontact...
TRANSCRIPT
EF in Core Business Apps & Domain-Driven Design ApproachesJulie Lerman
DEV-B336
consultant/mentorMicrosoft MVP, INETA Speaker,ASPInsider, MCP, VTdotNET Leader
blogtheDataFarm.com/blog
twitter@julielerman
book web siteLearnEntityFramework.com
Julie Lerman
GoalsEF in yourArchitecture
DDDBounded Context
Repository Pattern(s)& Unit of Work
Entities&Aggregates
Testing
Database
Data Access
UI
LINQ
& some Logic
Busines
s Logic
Separation of Concerns
Extensible
Adaptable Testable
Maintainable
Sensible!
UIBusiness/Domain LayerRepository/Unit of Work
Infrastructure/Data Access
Entity Framework
LINQTests
Tests
Database
Service Layer
Considering Context
Entity Framework DbContext
The “We Sell Stuff” Domain
CustomersSales
OrdersProducts
PaymentsShipments
Shippers
Promotions
SalesPeopleEmployees
SalaryHistory
Returns
Delimits the applicability of a particular model.
BOUNDING CONTEXTS gives team members
a clear and shared understanding of what has to be consistent
andwhat can develop independently.
- Domain Driven Design, Eric Evans 2003
“bounded context”
- Domain Driven Design, Eric Evans 2003
Bounded Contexts within a Domain
Customer Service
SalesBilling
Returns
Human Resources
Shipping
Marketing
Bounded Contexts within a Domain
Customer Service
SalesBilling
Returns Marketing
Human Resources
Shipping
Customers
SalesPeople
Shipments
Shippers
Order
Order
Items
Customer
ShipAddress
Customer
Order
Customer
Payments
Employee
SalaryHistory
Order
Customer
RMA
Credit
Items
Customer Service
Customer
SalesPerson
Addresses
ContactHistory
Promotion
Customers
Communications
Bounded Contexts within a Domain
Customer Service
SalesBilling
Returns Marketing
Human Resources
Shipping
Customers
SalesPeople
Shipments
Shippers
Order
ShipAddress
Payments
Employee
SalaryHistoryCustomer
RMA
Credit
Customer Service
Customer
SalesPerson
Addresses
ContactHistory
Promotion
Communications
ItemsToShip
Recipient
ItemsOrdered
Purchaser
Invoice
Payee
ItemReturned
Order Contacts
“Ubiquitous
Language”
Entities, Aggregates, etc.
Collection<EntityA>
Aggregate : Graph of Objects“Parent”
Entity
RelatedEntityA
Related Entity B
RelatedEntityA
RelatedEntityA
Aggregate Root
The Purchase
Aggregates & Aggregate Roots
Customer Order Stuff I
WantID
Sometimes . . .
All You Need Is CRUD
So . . .
What aboutthose mappings?Aggregat
e RootsValue
Objects
Can EF Handle Your Domain?
Entity Framework/Queries/Commands
Domain Model
PersistenceModel
Payments
InvoicesCustomers
DB Mappings,DB concerns,Follow EF rules
Domain Model
NewDatabas
e
LegacyDatabas
e
Payments
Credit
Invoice
Payee
Payments
Credit
Invoice
Payee
Credits
Repository &Unit of Work
Repository Essential:
“EncapsulateRedundantData Access
Code”
UIBusiness/Domain LayerRepository/Unit of Work
Infrastructure/Data Access
Entity Framework
LINQTests
Tests
Database
Service Layer
Basic RepositoryGet
Store
GetOrderById
AddOrder
RemoveOrder
GetAllOrders
GetCurrentOrders
GetCachedOrders
GetOrdersForCustomer
Remove
GetOrdersForProduct
Persist
Many variations…
One repo per
type? Read repos?Write
repos?
One repo per
aggregate?One
repo per
context?
Get
Store
Send to DB
Remove
Get
Store
Send to DB
Remov
e
CustomerRepo
Order Repo
Get
Store
Send to DB
Remove
AddressRepo
Customer
Orders
Addresses
Aggregate
Root
Order
Items
Testing with EF in the MixIntegratio
n/Interactio
n Tests
Unit Tests
EF Validation, State: No biggieDB: DropCreateDatabaseAlways No EF involved: Inconsequential
EF in the way: Abstraction/Interfaces/Mocking Lightweight DB e.g., MySql Refactor?
Unit of Work
Classes
UI
Testability: Faking EF
Tests
System.Data.Entity
Metadata &DbContexts
FakeContext & DataA
FakeDbSet
FakeContext & Data B
ositoriesositoriesositoriesRepositories
ClassesClassesClasses
SummarySave DB concerns for *later*Bounding contexts reduces complexitySometimes CRUD is all you needUse Aggregate Roots to manage graph objectsRepositories are a gateway to your dataAiming for Testability can Aid in Separating Concerns
ResourcesPluralsight On-Demand Training: pluralsight.comMSDN Developer Center: msdn.com/data/efEF Team: blogs.msdn.com/adonetLearnEntityFramework.comProgramming Entity Framework: DbContext
by Julie Lerman and Rowan Miller, O’Reilly Media, Feb 22 2012
“Domain Driven Design” Eric Evans, Addison-Wesley, 2003
“Implementing Domain Driven Design”, Vaughn Vernon, 2013
“N-Layered Domain-Oriented Architecture Guide with .NET 4.0” by César de la Torre, Unai Zorrilla, Javier Calvarro and Miguel Ángel Ramos (May 20, 2011)
domaindrivendesign.org“Separation of Concerns”, MSDN Magazine, http://juliel.me/Jhp6Pp
consultant/mentorMicrosoft MVP, INETA Speaker,ASPInsider, MCP, VTdotNET Leader
blogtheDataFarm.com/blog
twitter@julielerman
book web siteLearnEntityFramework.com
Julie Lerman
Related contentPositioning MS Dev Techs for Custom App Development(DEVB204) Cesar de la Torre
Developing Core Business Apps with DDD and .NET(DEV-B311) Jimmy Nilsson
Real Experiences & Architectural DDD Patterns Applied on .NET(DEV-B343) Per Rovegård
Entity Framework in Core Business Apps & DDD Approaches(DEV-B336) Julie Lerman
.NET Event Driven Applications, CQRS & Event-Sourcing in Mission-Critical Apps(DEVB401) June 6 10:15AM-11:30AM Greg YoungUnderstanding Dependency Injection and Those Pesky Containers(DEVB207) June 6 2:45PM-4:00PM Miguel Castro
TODAY
msdn
Resources for Developers
http://microsoft.com/msdn
Learning
Microsoft Certification & Training Resources
www.microsoft.com/learning
TechNet
Resources
Sessions on Demand
http://channel9.msdn.com/Events/TechEd
Resources for IT Professionals
http://microsoft.com/technet
Complete an evaluation on CommNet and enter to win!
Evaluate this session
Scan this QR code to evaluate this session and be automatically entered in a drawing to win a prize
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.