DDD Course Notes

DDD: Modeling Problems in Software

Bounded Context

Solution Space Concept

Describes how the software and software development gets broken down.

The Bounded Context is shaped to fit the Sub-Domain. Carpet is shaped to fit the floor.

A Bounded Context does not necessarily mean a separate application. To make it clear setup your application to be explicit as to where the contexts are.

• Where is the model valid?
• Concepts that make sense in one part of the application may not make sense in another.
• Even if they have the same name
• Even if they refer to the same thing
• A Client in the Appointment Context is different than a Client in the Billing Context
• Appointment Context:
• Name
• Identity
• Billing Context:
• Name
• Identity
• Credit Cards
• Address
• Billing Validation
• Credit Validation
• Each Bounded Context gets its own:
• Team
• Code Base
• DB Schema

Sub-Domain

Problem Space Concept

Describes how you’ve chosen to break down the business or domain activity.

Context Maps

A global view of the application as a whole. Each bounded context fits within the Context Map to show how they should communicate with each other and how data should be shared.

Which aspects of the system can a team modify on their own and which are shared dependencies must they coordinate with other teams.

Shared Kernel

A way to share concepts across Domains. For instance Authentication requires a User be defined once and authenticated the same. However, Appointment’s and Billing will both use it. Therefore, any changes being made to User must be coordinated between all the teams involved.

Ubiquitous Language

A single shared language for a Context for the whole team:

• Devs
• Business/Domain Owners
• Project Managers

Everyone uses the same words to mean the same things.
Ubiquitous language must be used everywhere inside the bounded context, from conversations to code.

Definitions

• Problem Domain
• The specific problem the software is trying to solve.
• Core Domain
• The key differentiator for the customer’s business – something they must do well and cannot outsource.
• Sub-Domains
• Separate applications or features your software must support or interact with.
• Bounded Context
• A specific responsibility, with explicit boundaries that separate it from other parts of the system.
• Context Mapping
• The process of identifying bounded contexts and their relationships to one another.
• Shared Kernel
• Part of the model that is shared by 2 or more teams, who agree not to change it without collaboration.
• Ubiquitous Language
• A language using terms from the domain model that programmers and domain experts use to discuss the system.

Elements of a Domain Model

Domain

The Domain Layer is responsible for representing concepts of the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

The Domain Layer is the heart of the business software.

Focus on the behaviors not the attributes.

Anemic Domain Models

Domain model that is focused on the state of its objects. Basic CRUD. Commonly, these are tables in DB mapped to objects with no functionality.

• This is the antithesis of DDD.
• Anemic is perfectly fine for CRUD.
• Anti-pattern in DDD
• Bags of getters and setters
• No domain logic in the domain objects.
• Instead there are set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

Rich Domain Models

A collection of objects that expose behavior.

Entities

Have identity and are mutable. Defined by their thread of continuity and identity.

• Uses GUID, Code controls the creation of the entity
• Track
• Locate
• Retrieve
• Store
• Most likely to become a table
• Are inside of a Domain and Not used for CRUD
• They require more complex handling
• Shouldn’t have a lot of different business logic in it.

Design an Entity with the identity and life cycle in mind. Identity isn’t just an ID field.

Identity matching can become so complex that it’s sometimes appropriate to have another object or set of functions be responsible for it.

Entities might delegate logic to value objects. Entity, “What should be done next?” Some service gets invoked to answer that question.

Entity Shouldn’t Have an Equality Comparison

A value object should always have a well-defined equals method. The concept is not quite right for entities.

• Is this referring to the same entity?
• Have I got 2 properties of the same object?
• What do you mean?

Are these 2 entities the same customer? Did we mess up and enter him/her twice?

Do I have the same ID for 2 different sets of data? We’ve got a distributed DB so things didn’t update across all nodes correctly.

Reference Type Entities (aka Reference Entities)

Read only types used as references inside of a Domain.

• Uses Int, DB controls the creation of the entity
• Not edited inside the Domain

We can reuse names in different Domains because of Namespaces.

Factory Methods

Static methods that do the creation of the entity and also validate the input. They help avoid entities being in an inconsistent state.

Relationships

Try to use unidirectional relationships. Bi-directional relationships can often lead to confusion.

A Relationship (or Association) should be part of a type’s definition. If 2 types have a bi-directional relationship it means that both types cannot be defined without one another. Make sure that’s the case.

A bidirectional association means that both objects can be understood only together. When application requirements do not call for traversal in both directions, adding a traversal direction reduces interdependence and simplifies the design.

Try to start with One-Way relationships.

YAGNI

Value Objects

Objects that are defined by their values.

• Measures, quantifies or describes a thing in the domain.
• Identity is based on composition of values
• Immutable
• Compared using all values
• No side effects
• Any methods should compute things not change the state

Money is a great example of a value object:

• Company worth
• ID: 2
• Worth Unit: US Dollars
• Worth Amount: 50000000
• Date: 2016-04-25

We should use Value Objects instead of Entities wherever possible. Even when a domain concept must be modeled as an Entity, the Entity’s design should be biased toward serving as a value container rather than a child Entity container.

You’re design’s will have Entities with very little logic of their own or very few primitives as their properties. Instead Entities will have lots of properties that are themselves Value Objects.

Sometimes when you’re looking at an entity there might be a couple of properties that seem to always go together. You might be able to bundle these properties into a single Value Object.

Value Objects are a better place to put methods and logic because we can do our reasoning without side effects and identity.

Value Objects are easier to test.

The Entity becomes the orchestrator of the Value Objects but can’t complete a lot of operations on its own.

Domain Services

When an operation is important to a model but does not belong on any Entity or Value Object a Domain Service is appropriate.

Domain Services serve as orchestrators for operations that require several different collaborating Entities or Value Objects.

Good Domain Services:

• Not a natural part of an Entity or Value Object
• Have an interface defined in terms of other domain model elements
• Are stateless (but may have side effects)

Live in the Core of the application.

Definitions

• Anemic Domain Model
• Model with classes focused on state management. Good for CRUD.
• Rich Domain Model
• Model with logic focused on behavior, not just state. Preferred for DDD.
• Entity
• A mutable class with an identity (not tied to its property values) used for tracking and persistence.
• Immutable
• Refers to a type whose state cannot be changed once the object has been instantiated.
• Value Object
• An immutable class whose identity is dependent on the combination of its values.
• Services
• Provide a place in the model to hold behavior that doesn’t belong elsewhere in the domain.
• Side Effects
• Changes in the state of the application or interaction with the outside world (e.g. infrastructure)

Aggregates in Domain-Driven Design

Aggregate

An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes.

Consist of one or more Entities or Value Objects that change together.

We need to treat them as a unit for data changes and we need to consider the entire aggregates consistency before we apply changes.

We treat a set of changes to everything in the Aggregate as a single transaction. Every Aggregate must have an Aggregate Root.

Every time you update an Aggregate you should do so in a transaction so all members of the Aggregate are updated.

Aggregates should follow ACID:

• Atomic
• Consistent
• Isolated
• Durable

Invariant

An invariant is a condition that should always be true for the system to be in a consistent state.

It’s the Aggregate Root’s responsibility to maintain its invariants.

For instance a Schedule Aggregate (in this instance the Root) should check if a Doctor or Room is double booked. Checking for the double booking of a Doctor or Room is the Invariant. The Schedule is responsible for including this rich behavior.

Examples of Invariants:

• The speed of light
• Total items on purchase order do not exceed a limit
• Two appointments do not overlap one another
• End date follows begin date

Aggregate Root

Aggregate Root is the parent object of all the members of the Aggregate.

You can have an Aggregate with just one object or only an Aggregate Root.

When evaluating if an object should be treated as an Aggregate Root, think about if deleting the object should trigger a cascade of deletion. If so it’s a good indication that you have an Aggregate Root.

Another way to think about Aggregate Roots, does it make sense to have this object detached from its parent? If so it might be an Aggregate Root.

Aggregate Relationships

Aggregates serve as boundaries between logical groupings in our application. We enforce these boundaries by prohibiting direct references to objects in an Aggregate that are not the Root.

If our Aggregate uses Entities or Values Objects not found in the Aggregate it should be a reference to them using the ID of the Entity or Value Object.

Aggregate Tips

• Aggregates are not always the answer
• Aggregates can connect only by the root
• You can use Foreign Keys inside a non-Root entities
• Too many Foreign Keys to non-root entities may suggest a problem
• Aggregates of one are acceptable
• Rule of Cascading Deletes: a way to tell if you have a correct Aggregate Root is if deleting it will delete should other Aggregates.

Definitions

• Aggregate
• A transactional graph of objects
• Aggregate Root
• The entry point of an aggregate which ensure the integrity of the entire graph
• Invariant
• A condition that should always be true for the system to be in a consistent state
• Persistence Ignorant Class
• Classes that have no knowledge about how they are persisted

Repositories

Repository

Applying model first design and separation of concerns means pushing persistence behavior into its own set of abstractions, referred to as Repositories.

Only Aggregate Roots should be available via global requests. Repositories provide this access and through omission prevent access to non-aggregate objects except through their aggregate roots. They give you the ability to constrain the data access so you avoid lots of random data access code throughout your application.

Repositories can be responsible for a lot of the grunt work behind the scenes. If we need to match up some data across entities and value objects the repository can do this:

• Get Schedule For Date
• Get Schedule Id For Clinic
• Get Appointments
• Get Highlights
• Add Highlights to Appointments
• Create Schedule Object and pass Appointments into the Schedule’s constructor
• Return the Schedule object

Unit of Work

Handles the coordination of multiple Repositories under 1 transaction.

Object Life Cycles

No Persistence:

• Create
• Do Stuff
• Destroy

With Persistence:

• Create
• Reconstitute from Persistence
• Do Stuff
• Save Changes to Persistence
• Destroy

Repository are used to handle the life cycle of your persistence objects without the objects having to know anything about the persistence.

Persistent Ignorant Objects: objects that don’t know how they get persisted.

“A repository represents all objects of a certain type as a conceptual set… like a collection with more elaborate querying capability.”

Repository Tips:

• Think of it as in-memory collection
• Implement a known, common access interface
• IRepository: Standard CRUD (add, remove, update, list)
• Methods for add & remove
• Methods that predefine criteria for object selection
• IScheduler.GetScheduleAppointmentsForDate returns a schedule object
• Repos for aggregate roots
• Client focuses on the model, repo focuses on persistence

Repository Benefits:

• Provides common abstraction for persistence
• Promote Separation of Concerns
• Communicates Design Decisions
• Enable Testability
• Improved Maintainability

Client code can be ignorant of repository implementation but developers cannot.

Common Repository Blunders:

• N+1 Query Errors
• One query to get the count and a query for each individual item in the list
• Inappropriate use of eager or lazy loading
• Fetching more data than required
• Do we need all the columns in the table?

IRepository can be useful but not necessary:

• Contains the common CRUD operations
• Implemented as a base for other Repositories
• Common Root specific Repository:
• Root : IEntity
• RootRepository: IRepository<Root>
• More DDD focused since we are constraining its use to Roots
• Generic Repository:
• Repository<TEntity> : IRepository<TEntity> where TEntity : class, IEntity
• Allows a dev to use the repository for non-Root Entities
• Generic Repository with Aggregate Root constraint:
• IAggregateRoot: IEntity
• Root: IAggregateRoot
• Repository<TEntity> : IRepository<TEntity> where TEntity : class, IAggreagateRoot
• var result = new Repository<NonRoot>().GetById(1) can’t be done

Factories

• Factories create new objects
• Repositories use factories to create objects
• Factories have no persistence whereas Repositories do.

Definitions

• Repository:
• A class that encapsulates the data persistence for an aggregate root
• ACID:
• Atomic: everything or nothing gets persisted
• Consistent: the constraints on the data are applied, any updates bring the database from one valid state to another valid state
• Isolated: if 2 different aggregates are being committed at the same time they don’t conflict as they’re being committed
• Durable: once the transaction occurs its permanent

Domain Events and Anti-Corruption Layers

Domain Events

Domain Events provide a way to describe an important activity or state changes that occur in the system. Other parts of the domain can respond to these events in a loosely coupled manor. The objects that raise the events don’t need to worry about the behavior that needs to occur when the event happens. Also, the event handling objects don’t need to know where the event came from.

Events can also be used to communicate outside of our domain.

Domain Events are encapsulated as objects. In UI events are written as delegates but in DDD events are first class members of the domain model.

“We should use a domain event to capture an occurrence of something that happened in the domain.”
The Domain Events should be a part of our Ubiquitous Language. Everyone should know what you’re talking about when you say, “Appointment Confirmed Event” was raised.

Instead of having all the behavior that might need to occur be defined in one place we can create an event and broadcast it out. Any class that needs to do something with that event is free to do so. We can separate out classes and adhere to the Single Responsibility Principal.

A Domain Event is a record about something that occurred in the past and might be of interest to other parts of our application.

Domain Event Tips:

• “When this happens, then something else happen.”
• Also listen for:
• “If that happens…”
• “Notify the user when…”
• “Inform the user if…”
• Domain Events represent the past
• Typically they are immutable
• Name events based on terms from the Ubiquitous Language describing clearly what occurred
• If they are fired as part of a command on a domain object be sure to use the command name
• YAGNI: only create events as you need them in your model
• Don’t create events unless you need some behavior to occur when the event takes place and you want to decouple the behavior from its trigger. Only needed when the behavior that’s needed in response to the event does not belong in the class that triggered it.

Designing Domain Events:

• Each event is its own class
• Include when the event took place
• Create a special interface with common event properties
• Public interface IDomainEvent
• DateTime DateTimeOccurred {get;}
• Capture event-specific details
• What would you need to know to trigger this event again?
• Consider including the identities of any aggregates involved in the event
• Event fields are initialized in constructor
• No behavior or side effects

Examples:

• User Authenticated
• Appointment Confirmed
• Payment Received

Hollywood Principal: “Don’t call us, we’ll call you.” Have classes not responsible for something broadcast events to other classes to handle behavior not suitable for the class sending the event.

Break your project out into the following folders and uses:

• Events:
• Models of the events that happened
• Handlers:
• Classes that respond to particular events
• NotifyUIAppointmentConfirmed : IHandle<AppointmentConfirmed>
• Interfaces:
• Where all your interfaces go, meh
• Model:
• The Aggregate(s)
• Repositories:
• Where all your repositories and unit of work classes go

The DomainEvents class can be found on Udi Dahan’s website. http://udidahan.com/2009/06/14/domain-events-salvation/

This class is used to route events inside your application.

A Schedule contains many Appointments. Since we don’t want the Appointment classes knowing about the Schedule class we broadcast an event that the Schedule is subscribed to.

Other classes outside of the domain can handle the events as well like the UI. Even your webpage can be updated using SignalR.

Domain Event Boundaries

• Create separate event objects for specific clients
• Create cross-system events for external clients
• Internal ID’s are not applicable for system’s outside our boundary
• Add details for external systems instead of having them request all the details separately
• Define specific application events for the UI layer

Anti-Corruption Layers

Anti-Corruption Layers are used to translate and insulate between a bounded context and foreign systems.

When you design a new system you need to make sure other Bounded Context’s and Legacy App’s assumptions and design decisions do not bleed into your model. For instance, if another system includes a customer, even if that customer refers to the same actual business customer, it’s likely that it will be modeled differently than in your system. It’s best to have a layer that can translate to and from other system’s models.

• Translate between the foreign system and your own
• Clean up the way you communicate with the other system
• Façade
• Adapter
• Custom Translation classes or services

“Even when the other system is well designed, it is not based on the same model as the client. Often the other system is not well designed.”

Definitions

• Domain Event
• A class that captures the occurrence of an event in a domain object
• Hollywood Principal
• “Don’t call us, we’ll call you”
• Inversion of Control (IoC)
• A pattern for loosely coupling a dependent object with an object it will need at runtime
• Anti-Corruption Layer
• Functionality that insulates a bounded context and handles interaction with foreign systems or contexts

SOLID – Single Responsibility Principal

“Every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.”

Our Goal

We have a few major goals when writing software:

1. Easily maintainable and modified: Software should be easily worked on by competent software engineers.
2. Understandable: A competent software engineer should be able to grok your code with little effort.
3. Work Correctly

Followed well, point’s 1 and 2 lead to 3 being true decades from now. Even if you’re indifferent to fellow employees’ struggles with terrible code, looking at your own poorly structured code from 6 months ago can be its own an arduous task.

Classes

This is where the Single Responsibility Principal comes in. We want to create small classes that do one thing well. This lightens the cognitive load when trying to understand how parts of a system work together.

Let’s take a look at an example:

public class ClaimsHandler
{
    public void AddClaim(Claim claim)
    {
        if (claim.UserId == null)
            throw new Exception("userId is invalid.");
        if (claim.DateOfIncident > DateTime.Now)
            throw new Exception("This feels like a scam.");
 
        using (var sqlConnection = new SqlConnection(connectionString))
        using (var sqlCommand =
            new SqlCommand("dbo.CreateClaim", sqlConnection)
            { 
                CommandType = CommandType.StoredProcedure 
            }) {

            sqlCommand.Parameters.Add("@UserId", SqlDbType.UniqueIdentifier)
                .Value = claim.UserId;
            sqlCommand.Parameters.Add("@DateOfIncident", SqlDbType.DateTime2)
                .Value = claim.DateOfIncident;

            sqlConnection.Open();
            sqlCommand.ExecuteNonQuery();
            sqlConnection.Close();
        }
    }
}

Our ClaimsHandler class is responsible for validating a claim and saving the data. Even though this example is only 28 lines long its needs to be broken up. Specifically, the validation and save logic need to go into their own classes. Why? The validation and save logic will change and become more complex as time goes on.

Let’s forward the clock a year:

public class ClaimsHandler
{
    public void AddClaim(Claim claim)
    {
        if (claim.UserId == null)
            throw new Exception("userId is invalid.");
        if (claim.Amount <= 0)
            throw new Exception("amount must be greater than $0.");
        if (claim.DateOfIncident > DateTime.Now)
            throw new Exception("This feels like a scam.");
        if (claim.User.Status == "Regular" &&
            claim.Amount > 3500)
            throw new Exception(
                "Regular accounts are not allowed to claim over $3500.");
        if (claim.User.MaxClaimAllowed < claim.Amount)
            throw new Exception(string.Format("User max claim is {0}.",
                claim.User.MaxClaimAllowed));
        if (claim.ClaimType == "Rental" && claim.User.Status != "Gold")
            throw new Exception(
                "Rental claims are only available for Gold members.");
 
        using (var sqlConnection = new SqlConnection(connectionString))
        using (var sqlCommand =
            new SqlCommand("dbo.CreateClaim", sqlConnection)
            { 
                CommandType = CommandType.StoredProcedure 
            }) {

            sqlCommand.Parameters.Add("@UserId", SqlDbType.UniqueIdentifier)
                .Value = claim.UserId;
            sqlCommand.Parameters.Add("@DateOfIncident", SqlDbType.DateTime2)
                .Value = claim.DateOfIncident;
            sqlCommand.Parameters.Add("@Amount", SqlDbType.Money)
                .Value = claim.Amount;
            sqlCommand.Parameters.Add("@ClaimType", SqlDbType.NVarChar)
               .Value = claim.ClaimType;

            sqlConnection.Open();
            sqlCommand.ExecuteNonQuery();
            sqlConnection.Close();
        }
    }
}

Both the amount of validation and number of items sent to the stored procedure increased. This class has also become more difficult to read.

What if the save or validation logic is used somewhere else? Keeping the changes consistent across all of the variations is difficult.

Let’s break this class up:

public class ClaimsHandler
{
    private readonly ClaimsRepository _claimsRepository =
        new ClaimsRepository();
    private readonly ClaimsValidation _claimsValidation =
        new ClaimsValidation();
 
    public void AddClaim(Claim claim)
    {
        _claimsValidation.Validate(claim);
        _claimsRepository.SaveClaim(claim);
    }
}
 
public class ClaimsValidation
{
    public void Validate(Claim claim)
    {
        if (claim.UserId == null)
            throw new Exception("userId is invalid.");
        if (claim.Amount <= 0)
            throw new Exception("amount must be greater than $0.");
        if (claim.DateOfIncident > DateTime.Now)
            throw new Exception("This feels like a scam.");
        if (claim.User.Status == "Regular" &&
            claim.Amount > 3500)
            throw new Exception(
                "Regular accounts are not allowed to claim over $3500.");
        if (claim.User.MaxClaimAllowed < claim.Amount)
            throw new Exception(string.Format("User max claim is {0}.",
                claim.User.MaxClaimAllowed));
        if (claim.ClaimType == "Rental" && claim.User.Status != "Gold")
            throw new Exception(
                "Rental claims are only available for Gold members.");
    }
}

public class ClaimsRepository
{
    public void SaveClaim(Claim claim)
    {
        using (var sqlConnection = new SqlConnection(connectionString))
        using (var sqlCommand =
            new SqlCommand("dbo.CreateClaim", sqlConnection)
            { 
                CommandType = CommandType.StoredProcedure 
            }) {

            sqlCommand.Parameters.Add("@UserId", SqlDbType.UniqueIdentifier)
                .Value = claim.UserId;
            sqlCommand.Parameters.Add("@DateOfIncident", SqlDbType.DateTime2)
                .Value = claim.DateOfIncident;
            sqlCommand.Parameters.Add("@Amount", SqlDbType.Money)
                .Value = claim.Amount;
            sqlCommand.Parameters.Add("@ClaimType", SqlDbType.NVarChar)
                .Value = claim.ClaimType;

            sqlConnection.Open();
            sqlCommand.ExecuteNonQuery();
            sqlConnection.Close();
        }
    }
}

We are now free to modify ClaimsValidation, ClaimsRepository and ClaimsHandler separately. If either the validation or the save logic changes we don’t have to modify ClaimsHandler.

Your class should only have one reason to change.

Systems

The Single Responsibility Principal applies not only to your classes but extends down into your methods, and variables. More importantly, it applies to individual systems and the whole company.

Let’s say we have a Calculate Service (one application) that contacts some other services and calculates some data before returning a result.

Our Calculate Service is already doing too much. It’s responsible for:

• Taking input from the Client Service
• Requesting data from Service A
• Requesting data from Service B
• Calculating a result
• Returning the result to the Client Service

Our application is brittle because it's doing too much it’s. Making a change to one responsibility has the potential to impact all other responsibilities. What happens when Data Service A’s API changes? What about when the calculations needed change? Each one of the responsibilities listed above should be their own application.

Let’s break this up:

This system looks more complex but all of this complexity was already present in the single Calculator Service. Moreover, it comes with the benefit of long term maintainability. If any responsibility changes we only need to make changes to that application and push it alone.

Another benefit of this new system is the ability to scale well. Before breaking up the system, if we needed to process more calculations we needed to push the whole application to more servers. However, if our Calculator Application is the bottleneck we can push just this one application to another server.

The Single Responsibility Principal is the most fundamental and important of the SOLID Principals. Apply it liberally, everywhere.

Reactive Systems

Manifestos

From time to time groups will try to succinctly dictate a series of guiding principals. A great example of this was the Agile Manifesto which taught software developers and their leadership to essentially adapt more than plan.

Until 2012 there was no succinct engineering explanation about the desired properties of a system built to take advantage of the cloud. The cloud used to be the territory of start ups who couldn't afford to personally run servers or web-scale companies who couldn't afford not to manage massive data centers all around the world.

More recently many companies of every size have seen the need for scalable systems. Due to massive increase in interest we are starting to see a consensus forming on the best practices for services in cloud environments. Enter the Reactive Manifesto.

Reactive Manifesto

The Reactive Manifesto was released in June 2012 by the good folks at Typesafe and Guru's like Erik Meijer.

The word "Reactive" is used because it's advocating systems that "reacts" to changes:

• React to Messages (Be Message Driven)
• React to Load (Be Elastic)
• React to Failures (Be Resilient)
• React to Users (Be Responsive)

Isolated Components

Before diving into the properties of a reactive system I think it's helpful to understand what an isolated component is.

An isolated component is a self-contained, encapsulated and isolated process. Your component could be a Window's service, Java Daemon, Erlang Module, RESTful API endpoint or any number of other technologies. It just has to isolate it's work from other components inside your system.

A and B are separate components. A and B do different work. They are isolated components.

Message-Driven

Having a Message-Driven system means relying on asynchronous messages between isolated components. We want to send a message to a different component in our system, have it read the message and do some work.

Let's take a look at an example:

1. Component A sends a message to component B.
2. B reads the message and does some work.

While this is a simple concept it's also powerful because:

• A and B are Loosely Coupled:
• A and B can be changed separately with little fear of one component's changes effecting the other.
• A and B do not need to be on the same piece of hardware or even in the same building. A can place a message on a Message Queue and it will eventually make it to B.
• B does not need to work on the message as soon as A is done. B can work on the message when it has the capacity to.
• B is Non-Blocking to A:
• A doing work is not tied to B being able to do work. After A sends the message to B, A is free to work on it's next task.
• B can give Back-Pressure to A:
• If B is falling behind on it's work, it can tell A to slow down or stop sending messages.
• Because we are using a Message Queue we achieve Location Transparency:
• A does not have to know where B is in physical space. A only needs to know the name of B's queue. The message will eventually make it to B.

Elastic

Your system needs to be elastic. Not only does your system need to be designed in a way that adding more capacity is a easy, it has to automatically add or remove capacity automatically. When the Reactive Manifesto was first introduced this property was named "Scalable." However, the authors didn't feel it emphasized automatic handling of capacity so it was changed to "Elastic."

A system has to be able to:

• Scale up
• Scale down
• Detect when a component has failed and relaunch it

This ensures the following features:

• Resilience:
• If a component dies it will be relaunched.
• Efficient use of resources: 
• If a system is on a public cloud, it will only be charged for the minimum amount of resources it needed.
• If it's in a private cloud, other systems of lesser priority will have access to resources when the resources become available.
• Responsiveness:
• If the system comes under heavy load we can scale to meet demand.

Resilience

Resilience is a measure of how quickly your system can recover from:

• Software Failures
• Hardware Failures
• Connection Failures

Because each component encapsulates its own work, failures do not propagate to other components. Moreover, if server dies or a component crashes our system will relaunch the component somewhere else.

Responsive

The system should provide rapid and consistent response times even:

• Under heavy load
• When failures are encountered

The system responding in an untimely manor is not just considered poor performance, it's considered a failure and should be dealt with automatically.

Four Principals Interacting

At this point it should be obvious that each principal overlaps with other principals. Having a responsive system also means having a resilient system for the same basic reasons. This is usually demonstrated by showing the following diagram:

Message-Driven supports all of the other properties of Reactive Systems. Elastic and Resilient support each other and Responsive.

An N-Tier Application

Let's try to apply these principals. We want to build a system that:

• Takes a request
• Contacts an external resource for some data
• Does a calculation
• Stores the result

An N-Tier system would look like:

This design is fine for a small system that does not experience a lot of traffic. Limited to thousands of requests a day, this a perfectly appropriate solution. However, if it gets hundreds of thousands or millions of requests we need to start breaking it apart into isolated components.

This design also suffers from a number of problems:

• All work for each request is done all at once:
• If any part of the system fails, including the External Resource (which our system has no control over) the whole request fails and must be tried again.
• Parts of our system sit idle waiting for other parts to finish. The Business Layer cannot do calculations until a result is returned from the External Resource.
• In order to scale this application we have to deploy the whole system multiple times.
• If we need to update one piece of the system there is a higher probability of effecting functionality in a different layer.

A Reactive Implementation

Let's take a look at a reactive implementation.

While this system is more complicated it provides a number of benefits:

• Independent Scalability:
• If Calculator takes more time to do work the system can spin up more instances of it independent of the rest of the system.
• Isolated Components:
• If Calculator fails or is slow it will not stop Data Retriever or DB updater from working.
• The External Resource's impact to our system is isolated to the Data Retriever component.
• I can make changes to any component with little fear of effecting the other components.
• These components can be spread across the globe and I don't have to know their locations.

It's All Been Done Before

The principals outlined in the Reactive Manifesto are not new. In the 80's Erlang was using them. There's even significant overlap in Service Oriented Architecture and Microservices. However, having a succinct and accessible way to communicate a complex topic like cloud architecture is a great way to get discussions going inside of companies.

Dapper - A Simple ORM

Entity Framework

Entity Framework is a full featured ORM. This is nice when performance is not important but rapid development is. Coding Linq statements instead of stored procedures can speed implementation dramatically.

EF's ease of use has trade-offs. All the behind the scenes work means slower performance and frustrating gotchas. Occasionally EF's generated SQL differs from the desired result. This inevitably necessitates a greater understanding of EF's inner workings. At that point it's just easier to write your own SQL.

Dapper

Dapper is a Micro-ORM. It focuses on simplifying database interactions with extension methods for query and execute commands. It also auto-maps values to POCO objects.

That's more or less it. Because Dapper's not managing relationships and data in memory its performance is an order of magnitude better.

According to Dapper's Github Page, “Select mapping over 500 interactions and POCO serializations” section:

• Hand Coded: 47ms
• Dapper: 49ms
• Entity Framework: 631ms

There is almost no performance hit because Dapper doesn't do too much.

Stored Procedure Example

Let's write code to return a list of Diamond Club Members from a Stored Procedure.

Here's our POCO:

private class Member
{
    public string Guid {get;set;}
    public string Name {get;set;}
    public string MemberType {get;set;}
}

Let's look at an ADO.NET example:

private IEnumerable<Members> GetAllDiamondClubMembers()
{
    using (var sqlConnection = new SqlConnection(connectionString))
    using (var sqlCommand = new SqlCommand(
        "dbo.GetAllMembers", sqlConnection){
             CommandType = CommandType.StoredProcedure }) {

        sqlCommand.Parameters.Add("@MemberType", SqlDbType.VarChar)
            .Value = "DiamondClub";

        sqlConnection.Open();

        var sqlDataReader = sqlCommand.ExecuteReader();

        var members = new List<Members>();

        while(sqlDataReader.Read())
        {
            members.Add(new Member
            {
                Guid = sqlDataReader["Guid"],
                Name = sqlDataReader["Name"],
                MemberType = sqlDataReader["MemberType"]
            });
        }

        sqlConnection.Close();

        return members;
    }
}

In the above example we are:

1. Creating a SQL Connection
2. Creating a SQL Command
3. Loading the SQL Command
4. Opening the SQL Connection
5. Executing the Stored Procedure
6. Iterating through the returned values
7. Mapping each individual value
8. Closing the connection
9. Returning the results

Dapper dramatically simplifies this:

private IEnumerable<Members> GetAllDiamondClubMembers()
{
    IEnumerable<Members> results;

    using (var sqlConnection = new SqlConnection(connectionString))
    {
        sqlConnection.Open();
        results = sqlConnection.Query("dbo.GetAllMembers", 
            new { MemberType = "DiamondClub" },
            commandType: CommandType.StoredProcedure);
    }

    return results;
}

Now we:

1. Create the SQL Connection
2. Open the SQL Connection
3. Run the Query
4. Return the results

Dapper has taken care of most of the rudimentary details for us. This is a healthy compromise between Entity Framework's performance hit and ADO.NET's code requirements.

Microsoft Unity IoC Container

SOLID

Because we’re following SOLID code design we should have:

• Small classes
• Concrete classes that implement interfaces (with very few exceptions)
• Any interactions with a concrete class should be done using the interface
• Classes that other classes depend on should be injected into them during instantiation (preferably using the constructor)

A natural outgrowth of these rules is IoC.

IoC

IoC stands for Inversion of Control. It’s a byproduct of the Dependency Inversion principal. Instead of classes higher in the dependency chain determining what concretion of a class they should be using, a separate context determines which concretions get used.

This is confusing so let’s take a look at some sample code.

public class A
{
    public void LogIt()
    {
        var log = new Log();
        log.LogMe("I'm not testable!");
    }
}

public class Log
{
    public void LogMe(string message)
    {
        Console.WriteLine(message);
    }
}

In this example A creates an instance of Log and calls the LogMe method. A is Higher on the dependency chain and determines which class to use to call the LogMe method.

This is bad for a few reasons:

• I can’t test A desperately from Log. For larger classes and more dependencies this makes unit testing impossible. As the different possibilities pile up (code paths or combinations) testing become exponential.
• If I want to change A's use of Log but preserve Log in it's current form (if other classes use Log) I am forced to modify A as well. This is especially frustrating if I want to call LogMe still.

Let’s take a look at a more maintainable code base:

public class A : IA
{
    private readonly ILog _log;
 
    public A(ILog log)
    {
        _log = log;
    }

    public void LogIt()
    {
        _log.LogMe("A is now testable!");
    }
}

public interface IA
{
    void LogIt();
}

public class Log : ILog
{
    public void LogMe(string message)
    {
        Console.WriteLine(message);
    }
}
 
public interface ILog
{
    void LogMe(string message);
}

The above example's code has increased some because we inject a concrete instance of Log as an interface ILog into A. A is now not in charge of determining what concrete implementation of ILog is used. We've also created interfaces for both A and Log.

This is:

• Testable: I can test A and Log separately.
• Swappable: If I need to I can specify a different concretion of ILog with no modification to A.

Notice that the concreate implementation of ILog is injected into A’s constructor and the interface ILog is private inside of A. This is called Constructor Injection.

There’s also a concept called Property Injection where a class exposes its dependencies as public properties. This is not a good idea as other classes could change your dependencies.

Enter MS Unity IoC Container

This leaves us with a problem. How do we organize and assemble all these classes together? In particular, if we have lots of small classes that call each other there’s going to be a lot of work done up front.

You can manually assemble the classes when your application first starts but it quickly becomes chaos and hard to read.

How do we avoid the mess that manually assembling dependencies together creates? Inversion of Control (IoC) Containers to the rescue.

IoC Containers provide a framework for organizing and managing dependencies inside your application. We will be using Microsoft Unity IoC Container in this example to assemble our dependency chain.

Let’s take a look at some code:

public static void AssembleDependencies()
{
    var unityContainer = new UnityContainer();

    unityContainer.RegisterInstance<ILog>(new Log());
    
    unityContainer.RegisterType<IA, A>(
        new InjectionConstructor(
            container.Resolve<ILog>()
        )
    );
}

RegisterType tells Unity to create a new instance of the concrete class anytime one is needed. In our example if A get's used multiple times Unity will create new instances each time.

RegisterIntance tells Unity to create and use only one instance for a specific lifetime. More often then not you will only need one instance of a logger (Log) for your application so here RegisterInstance only creates one.

This is kind of like the difference between using a Factory design pattern and a Singleton design pattern:

• Factory is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created.
• Singleton is a design pattern that restricts the instantiation of a class to one object.

RegisterType is a kind of Factory pattern with more capability. You use it when a new instance of a class is needed each time that class is used.

RegisterInstance is a kind of Singleton pattern with more capability. You use it when you only want one instance of a class in the whole application. However, you can also tell Unity when you want to expire the class and create a new one as well.

unityContainer.RegisterInstance<ILog>(new Log());

I used RegisterInstance for Log. In most applications you will only need one instance of a Logger. In this case we create the instance of Log and associate it with ILog. Now anytime unity is asked to resolve ILog it will create a concrete implementation of Log and return it as ILog.

unityContainer.RegisterType<IA, A>(
    new InjectionConstructor(
        container.Resolve<ILog>()
    )
);

I used RegisterType for A. Since A will be created more than once we want to give Unity instructions about what to inject into it and not actually create an instance now. InjectionConstructor is what keeps track of what dependencies should be injected into the constructor of A.

Note that we can now inject A in another class by resolving IA:

new InjectionConstructor(
    container.Resolve<IA>()
)

We've has only scratched the surface of Microsoft Unity IoC capabilities but I hope I've provided you a good start to developing more manageable code bases.

Web API 2 Message Handlers and Filters

Message Handlers

Custom Message Handlers

Custom message handlers are used for cross cutting concerns like logging or authorization.

Lets look at the Message Handler Pipeline we will be building:

HttpServer gets the initial message from the network. FooHandler and LogEverythingHandler are custom handlers created for our cross cutting concerns. HttpRoutingDispatcher functions as the last handler in the list responsible for sending the message to the HttpControllerDispatcher. The HttpControllerDispatcher then finds the appropriate controller and sends the message to it.

Let’s take a look at some code:

public class FooHandler : DelegatingHandler
{
    private readonly IBarProvider _provider;

    public FooHandler(IBarProvider provider)
    {
        _provider = provider;
    }

    protected async override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request,
        System.Threading.CancellationToken cancellationToken)
    {           
        if (_provider.DoesRequestContainBar(request))
        {
            return await base.SendAsync(request, cancellationToken);
        }

        var response = request.CreateErrorResponse(HttpStatusCode.BadRequest, 
            "Request does not contain bar.");

        return response;
    }
}

The following 3 rules need to be followed to create a custom message handler:

1. Your class must inherit from the DelegatingHandler class.
2. You must implement the SendAsync class.
3. You must call base.SendAsynch to pass the message to the next custom message handler.

If we wanted to we could create another class to log every request to our API.

In order to tell Web API that we want these custom message handlers added to the pipeline we need to add some code the WebApiConfig class.

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MessageHandlers.Add(new FooHandler());
        config.MessageHandlers.Add(new LogEverything());
    }
}

Execution Order

With our custom message handlers added to the pipeline the following becomes the order of execution:

• HttpServer
• FooHandler
• LogEverything
• HttpRoutingDispatcher
• HttpControllerDispatcher

This illustrates how custom message handlers give us the ability to apply general rules to all the messages coming into our API’s.

Filters

This quote beautifully illustrates the difference between Handlers and Filters:

“The major difference between their two is their focus. Message Handlers are applied to all HTTP requests. They perform the function of an HTTP intermediary. Filters apply only to requests that are dispatched to the particular controller/action where the filter is applied.”

Filters get applied to the individual controllers using attribute tags above a class or method.

Global Exception Filters

We can add exception filters to controller methods.

Let’s take a look at the following Filter and corresponding Controller.

public class UnauthorizedFilterAttribute : ExceptionFilterAttribute
{
    public override void OnException(HttpActionExecutedContext context)
    {
        if (context.Exception is UnauthorizedException)
        {
            context.Response =
                new HttpResponseMessage(HttpStatusCode.Unauthorized);
        }
    }
}

public class ProductsController : ApiController
{
    [UnauthorizedFilterAttribute]
    public Baz GetBaz(int id)
    {
        throw new UnauthorizedException("This method is not authorized.");
    }
}

In the above example UnauthorizedFilterAttribute is decorating ProductsController’s GetBaz method.

This gives us a clean separation between exception handling and controller logic. This also allows us to reuse the exception filter.

However, we can also make our exception filters global.

public sealed class GlobalExceptionFilterAttribute : ExceptionFilterAttribute
{
    public override void OnException(
        HttpActionExecutedContext httpActionExecutedContext)
    {
        if (httpActionExecutedContext != null)
        {
            if (httpActionExecutedContext.Exception is FooException)
            {
                var fooException = 
                    httpActionExecutedContext.Exception as FooException;
                httpActionExecutedContext.Response = 
                    new HttpResponseMessage(fooException.Code)
                {
                    Content = new StringContent(fooException.Message)
                };
            }
            else
            {
                httpActionExecutedContext.Response =
                    new HttpResponseMessage(
                        HttpStatusCode.InternalServerError)
                {
                    Content = new StringContent("There was a problem!")
                };
            }
        }
    }
}

Our GlobalExceptionFilterAttribute inherits from the ExceptionFilterAttribute. It also has only one overridden method named OnException. This class handles the response that should be sent back to the client.

public sealed class GlobalLogFilterAttribute : ExceptionFilterAttribute
{
    public override void OnException(
        HttpActionExecutedContext httpActionExecutedContext)
    {
        if (httpActionExecutedContext != null)
        {
            Logger logger = new Logger();
            logger.Error("There was an exception: {0}",
                httpActionExecutedContext.Exception.Message);
        }
    }
}

In the case of the GlobalLogFilterAttribute we can handle logging errors.

We now have a mechanism to:

• Log exceptions at the controller level
• Handle Errors that arise from the controller level

If all of our controller methods have the same logging and client exception response needs we've saved lots of coding. We've also ensured that fixes to the logging and client exception response don’t get partially implemented across only some controllers.

How do these “Global” exceptions get applied?

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MapHttpAttributeRoutes();

        config.Filters.Add(new GlobalLogFilterAttribute());
        config.Filters.Add(new GlobalExceptionFilterAttribute());
    }
}

Inside the WebApiConfig class the HttpConfiguration has a global filter list that can have custom Filters added to it.

Unit Testing using Moq and Microsoft Fakes

Your code should be unit tested. Most of the time this is a straight forward process. Using Dependency Injection, and tools like Moq can get you 90% of the way there.

In this article I will be outlining the very basics of Unit Testing using Moq, Microsoft Test Tools, Microsoft Fakes and cover a problem with Fakes where obscure .NET Framework Class Library classes aren’t accessible.

Stubs

Stubs provide a substitute concretion for interfaces used in code that requires testing. Following the Dependency Inversion Principal outlined in SOLID code design:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.

Let’s look at an example:

public interface IBar

{

   string WhatDoISay();

}

public class Bar : IBar

{

   public string WhatDoISay()

   {

       return "barbar";

   }

}

The class Bar contains the method WhatDoISay which returns a string. Our interface IBar contains the contract for the method WhatDoISay. Any class that inherits from IBar must implement WhatDoISay or the compiler will throw an error.

public class Foo

{

   public string Speech { get; set; }

   public void Run(IBar bar)

   {

       Speech = bar.WhatDoISay();

   }

}

Foo takes in the interface of IBar as a parameter. Since an interface cannot be instantiated it must be a pointer to a concrete class that implements IBar’s method, in particular WhatDoISay. After calling WhatDoISay the returned result is written to the Console.

Finally we have the entry point of the application, Program.

class Program

{

   static void Main(string[] args)

   {

       IBar bar = new Bar();

       Foo foo = new Foo();

       foo.Run(bar);

       Console.WriteLine(foo.Speech);

       Console.ReadLine();

   }

}

Program creates an instance of Foo and Bar. It then passes bar into Foo’s Run method and display’s its Speech property.

The result is to display “barbar.”

Let’s test this.

• Right click on your Solution and select Add -> New Project.
• In the left side project tree navigate to Visual C# -> Test.
• Select Unit Test Project and give it a name, preferably the project name with .Test at the end.
• Click Ok.

We now have a Test Project.

Before we can start testing our class Foo we have to add a reference to the project where it’s located.

Right click on Reference in the Solution Explorer and Select Add Reference….

Select Solution -> Projects -> TestApp and click OK.

Let’s create a file where the testing will take place.

Right click on the project, select Add -> Unit Test… and rename the file to FooTest.cs.

using System;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace TestApp.Tests

{

   [TestClass]

   public class FooTest

   {

       [TestMethod]

       public void TestMethod1()

       {

           

       }

   }

}

TestMethod1 is where we will put our code to Test Foo but first let’s name it something a little more appropriate.

[TestMethod]

public void WhatDoISay_ReturnAValidString_RunsCorrectly()

Since we will have many tests for each method inside of our class we should be specific about the name of the method to be tested, input and or important details and the expected outcome.

For our first unit test we want to make sure a different string is written to the console. Let’s create a Stub class that will output a different string, then make sure that string was set to the Property Speech in Foo.

public class FakeBar : IBar

{

   public string WhatDoISay()

   {

       return "fakebarbar";

   }

}

Now let’s set up our test.

[TestMethod]

public void WhatDoISay_ReturnAValidString_RunsCorrectly()

{

   Foo target = new Foo();

   FakeBar fakeBar = new FakeBar();

   target.Run(fakeBar);

   Assert.AreEqual(target.Speech, "fakebarbar");

}

We create the “target” to test, which in this case is an instance of Foo, instantiate FakeBar, pass it into the target’s Run method and Assert that target’s Speech property got set to our desired string.

What if we want to track the number of times WhatDoISay got called? It should be simple enough to add a counter to the FakeBar class and increment it every time WhatDoISay gets called.

[TestClass]

public class FooTest

{

   [TestMethod]

   public void WhatDoISay_ReturnAValidString_RunsCorrectly()

   {

       Foo target = new Foo();

       FakeBar fakeBar = new FakeBar();

       target.Run(fakeBar);

       Assert.AreEqual(target.Speech, "fakebarbar");

       Assert.AreEqual(fakeBar.NumberOfTimesWhatDoISayGotCalled, 1);

   }

}

public class FakeBar : IBar

{

   public int NumberOfTimesWhatDoISayGotCalled = 0;

   public string WhatDoISay()

   {

       NumberOfTimesWhatDoISayGotCalled++;

       return "fakebarbar";

   }

}

I now want to test what happens when I throw an error. I have to create another FakeBar that’s WhatDoISay method throws an exception. At this point it should be obvious this gets messy very, very quickly. This is where Moq comes in.

Moq is Mocking Framework that provides capable stubs with features accessed using lambda statements. Not only does this make designing stub behavior easy, it also makes your code more readable.

Let’s rewrite our last example using Moq.

In our Test project right click on References and select Manage NuGet Packages….

Type Moq in the upper right corner search field. When the search is done click on the Install button next to “Moq: an enjoyable mocking library” and close it.

We now have a reference to our Moq library.

Let’s get started.

Add using Moq; to the top of your test file.

using System;

using Moq;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace TestApp.Tests

We’re going to do a few things in the code below:

• Replace FakeBar with its mock.
• Setup the desired behavior when WhatDoISay is called.
• Pass its object into target’s run method.
• Check the number of times WhatDoISay gets called.

[TestMethod]

public void WhatDoISay_ReturnAValidString_RunsCorrectly()

{

   Foo target = new Foo();

   Mock<IBar> barMock = new Mock<IBar>();

   barMock.Setup(m => m.WhatDoISay()).Returns("fakebarbar");

   target.Run(barMock.Object);

   Assert.AreEqual(target.Speech, "fakebarbar");

   barMock.Verify(m => m.WhatDoISay(), Times.Once());

}

One extra line of code in the method to get rid of our FakeBar class implementation.

Let’s test what happens when we throw an exception.

[TestMethod]

public void WhatDoISay_ThowsAnException_ExceptionCaught()

{

   Foo target = new Foo();

   Mock<IBar> barMock = new Mock<IBar>();

   barMock.Setup(m => m.WhatDoISay()).Throws(new Exception());

   bool exceptionCaught = false;

   try

   {

       target.Run(barMock.Object);

   }

   catch

   {

       exceptionCaught = true;

   }

   Assert.AreEqual(exceptionCaught, true);

   barMock.Verify(m => m.WhatDoISay(), Times.Once());

}

Again, no extra class had to be created to throw the exception and we are still free to see the results.

Shims

What happens when you have code that has not been interfaced out? Interfacing every .NET Framework Class library would be time consuming and annoying. It would also overly complicate your code base.

Let’s take a look at this in action.

public class Baz

{

   public bool DoesDirectoryExist { get; set; }

   public void Run()

   {

       string path = "C:\\temp\\";

       DirectoryInfo directoryInfo = new DirectoryInfo(path);

       DoesDirectoryExist = directoryInfo.Exists;

   }

}

   

class Program

{

   static void Main(string[] args)

   {

       Baz baz = new Baz();

       baz.Run();

       Console.WriteLine(baz.DoesDirectoryExist);

       Console.ReadLine();

   }

}

Baz calls DirectoryInfo’s Exists method and stores the value in its DoesDirectoryExist property.

DirectoryInfo is now a dependency whose behavior we can’t control because:

• It was not interfaced out.
• It was not injected.

What if we want to test DirectoryInfo throwing an Exception? Microsoft Fakes to the rescue.

“Microsoft Fakes help you isolate the code you are testing by replacing other parts of the application with stubs or shims.”

Let’s create shims of the .NET Framework System library.

Right click on the System library under Reference and select Add Fakes Assembly.

It will take a few moments to generate your fakes.

You will now have 2 new libraries under References:

• mscorlib.4.0.0.0.Fakes
• System.4.0.0.0.Fakes

We also have a Fakes folder containing:

• mscorlib.fakes
• System.fakes

More on those later.

In our test class we have to add a new using: using Microsoft.QualityTools.Testing.Fakes;

Let’s take a look at our new Test Method.

[TestMethod]

public void GetDirectoryExists_ThowsAnException_ExceptionCaught()

{

   Baz target = new Baz();

           

   bool exceptionCaught = false;

   try

   {

       using (ShimsContext.Create())

       {

           System.IO.Fakes.ShimDirectoryInfo.ConstructorString = (x, y) => { };

           System.IO.Fakes.ShimDirectoryInfo.AllInstances.ExistsGet = _ =>

           {

               throw new Exception();

           };

           target.Run();

       }

   }

   catch

   {

       exceptionCaught = true;

   }

   Assert.AreEqual(exceptionCaught, true);

}

ShimsContext provides a context in which out custom shim functionality applies.

The ShimDirectoryInfo.ConstructorString specifies what we want to happen when the constructor is run. In this example we don’t want anything to happen.

Finally! We get to our desired test case. The ShimDirectoryInfo.AllInstances.ExistsGet is where we specify that calling Exists will throw the exception. Notice the AllInstances in the lambda expression? This means every instance of DirectoryInfo will behave in this way. Be careful when shimming a class that is used more than once. It may require more work in the lambda method.

Where the hell is System.IO.Path?

I ran into this annoying problem with Microsoft Shims and Fakes.

One more code example:

public class Qux

{

   public string FilePath { get; set; }

   public void Run()

   {

       string fileName = "a.pdf";

       string path = "C:\\a\\";

       FilePath = Path.Combine(path, fileName);

   }

}

class Program

{

   static void Main(string[] args)

   {

       Qux qux = new Qux();

       qux.Run();

       Console.WriteLine(qux.FilePath);

       Console.ReadLine();

   }

}

Qux uses Path.Combine to smooth over any missing slashes when combining parts of a path.

Let’s go unit test this.

Where the hell is Path? What about FileInfo’s Extension method?

It turns out when MS Fakes goes through and shims a library it doesn't shim every class. Any methods not shimmed on the first try have to be specified somewhere else.

Path is a static class and FileInfo’s Extension method is inherited from its base class, FileSystemInfo.

Remember our .fakes files?

mscorlib.fakes and System.fakes are XML files that allow you to specify any extra classes you need shimmed.

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">

 <Assembly Name="mscorlib" Version="4.0.0.0"/>

</Fakes>

Let’s add our Path and FileSystemInfo classes to mscorlib.fakes, save and compile.

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">

 <Assembly Name="mscorlib" Version="4.0.0.0"/>

 <ShimGeneration>

   <Add FullName="System.IO.Path"/>

   <Add FullName="System.IO.FileSystemInfo"/>

 </ShimGeneration>

</Fakes>

Now we can shim Path and FileSystemInfo till our hearts’ content.