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

Data Access

Business

Presentation

Data Access

Business

Presentation

Layers – any problems?

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;

}

}

public bool IsAdult { // business rule

get {

return this.Age >= 18;

}

}

...

Strong coupling!

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!

A new default architecture

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

PatientService

Log4netLogger

PatientRepositoy

Dependency Injection

Builder PatientService

Log4netLogger

ILogger

3) uses 2) inject dependencies

1) creates

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

Questions?

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

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

The end…Thank you!