Elements of DDD with ASP.NET MVC & Entity Framework Code First

Elements of DDD with
ASP.NET MVC &
Entity Framework Code First
Gabriel ENEA
Software developer / Maxcode.ro
Co-founder Joobs.ro – primul portal de joburi IT

07 may 2011

Updated:
Elements of software design

07 may 2011

Agenda Tags
# Unit Testing
# Enterprise Application Architecture
# Dependency Injection
# ASP.NET MVC 3
# Entity Framework 4.1 Code First
# Domain-Driven-Design
# Design Patterns

How do you start building an
application architecture?
Focus on?
 building an architecture from scratch
 thinking about how to achieve unit testing
 start with modeling the database schema and data relations
 using drag & drop programming
 modeling the domain entities, relations, business rules

 but, in the end, do you achieve 99,99% of unit testing?

Is unit testing realizable? 100%?
Yes or No? Who knows?

Maybe not! Possible answers:
 The customer doesn't understand this need
 Neither the management staff
 Instead, everyone expects you to write the perfect code

 As developers, every time we say: we need time to do it
right!

 But, do we need time or we don't know how to achieve it?

Let's start thinking to architecture
design?
What? Right, now!?

Hey, we have only 1 hour to finish this
presentation! 

Indeed, but let's try to do something!

Some directions
Modeling approaches
 Database First Design
 Model First Design
Layers
 How do we design them?
Business rules
 Where and how do we implement?
Persistence
 Should we use an ORM?

Modeling approach - Pros/Cons
Database First Design
 doesn't focus on business rules, only on the way the
data is represented

Model First Design
 Conceptual Design
 defines a conceptual model of the entities and relations
(UML vs. Domain-Specific Languages)
 Code First Design
 starts writing code: classes, properties, associations,
businesss rules

Layers

Presentation

Business

Data Access

Presentation

Layers – any problems? Business

Data Access

Layers Coupling!

A strong coupling conducts to a hard way to do:
 unit testing
 refactoring
 agile development
 or be opened for changes

Business rules
Where should these be located?
 Database
 Business layer
 User Interface (aka code behind!)

How do we test them?
 Running the application
 Automatically, maybe using unit tests
 Or we should let the customer test them!? 

And...what's inappropriate in this
code?
// somewhere in the business layer
...
public class Patient {
public DateTime Birthdate { get; set; }

public int Age { // computed value
get {
return DateTime.Now.Year - this.Birthdate.Year;
}
} Strong coupling!

public bool IsAdult { // business rule
get {
return this.Age >= 18;
}
}
...

Let's start with a new approach...DDD
Domain-Driven-Design
 What is Domain?

A new default architecture where:
 the database is not the first focus
 the layers are loosely coupled
 the business rules are within the application Domain
 it is easier to achieve unit testing

 Why? Today we have the tools!

Persistence
Requirements
 Persistence Ignorance (PI) / POCO
 Help Domain Model stay out of infrastructure stuff
 Decide where to store data
 Use code generation or an Object Relation (O/R) Mapper
 Metadata mapping
 Support for the Unit of Work pattern

Building blocks of Domain-Driven
Design

Today's tools
(from a web developer perspective)
ASP.NET MVC 3
 a mature web development platform based on
MVC pattern
Entity Framework 4.1 Code First / NHibernate
 helps you focus on your domain
DI frameworks
 Manage dependencies
 Castle Windsor, StructureMap, Spring.NET, Unity, ...

Stop, What is DI?
 = DI.Equals(IoC); // true or false?

 IoC = Inversion of Control
 DI = Dependency Injection

 Helps you to decouple the application dependencies
 Logging mechanisms (log4net, Enterprise Library Logging
Application Block, ...)
 Persistence mechanism (direct access to database, ORM)
 User Interface dependencies on Domain services

Dependency Injection

Log4netLogger

PatientService

PatientRepositoy

Dependency Injection
1) creates
Builder PatientService

Log4netLogger
2) inject dependencies 3) uses

ILogger

Persistance with EF 4.1 CodeFirst
Benefits
 Mapping based on predefined conventions
 Support for Query Object pattern (LINQ - IQuerable
interface)
 Fluent API for manual mapping entities to tables, no
more .edmx files
 Entity Validation

ASP.NET MVC 3 and DI support
 Based on MVC pattern
 Provides better support for IoC
 Views/Controllers

 Check IDependencyResolver interface
 simplify service location and dependency resolution

TService GetService<TService>() { … }

IEnumerable<TService> GetServices<TService>() { … }

Demo

What? We have a demo? Finally!

Conclusions
Focus on
 Analyze application dependencies
 Business rules
 Do refactoring!
 Design your Domain
 Don’t forget to do Unit testing

Resources
Books
 Domain-Driven Design, Tackling Complexity in the
Heart of Software, by Eric Evans
 Applying Domain-Driven Design and Patterns, With
Examples in C# and .NET, by Jimmy Nilsson

Online resources
 http://domaindrivendesign.org/
 http://www.infoq.com/minibooks/domain-driven-design-quickly

The end…Thank you!

Elements of DDD with
ASP.NET MVC &
Entity Framework Code First
Gabriel ENEA
Software developer / Maxcode.ro
Co-founder Joobs.ro – primul portal de joburi IT

07 may 2011

Elements of DDD with ASP.NET MVC & Entity Framework Code First

More Related Content

What's hot (20)

Similar to Elements of DDD with ASP.NET MVC & Entity Framework Code First (20)

More from Enea Gabriel (10)

Recently uploaded (20)

Elements of DDD with ASP.NET MVC & Entity Framework Code First