Click here to Skip to main content
13,249,174 members (34,962 online)
Click here to Skip to main content
Add your own
alternative version


9 bookmarked
Posted 9 Sep 2014

Put your BLL monster in Chains

, 9 Sep 2014
Rate this:
Please Sign up or sign in to vote.
This article shows how to use the FubuMVC's behavior chains pattern (BMVC) to improve BLL maintainability


A very popular architecture for enterprise applications is the triplet Application, Business Logic Layer (BLL), Data Access Layer (DAL). For some reason, as time goes by, the Business Layer starts getting fatter and fatter losing its health in the process. Perhaps I was doing it wrong.

Somehow very well designed code gets old and turns into headless monster. I have ran into a couple of these monsters that I have been able to tame using FubuMVC's behaviour chains. A pattern designed for web applications that I have found useful for breaking down complex BLL objects into nice maintainable pink ponies.

Paradise beach service

I need an example to make this work. So let's go to the beach. Spain has some of the best beaches in Europe. Let's build a web service to search for the dream beach. I want the clients to enter some criteria: province, type of sand, nudist, surf, some weather conditions as some people might like sun, others shade and surfers will certainly want some wind. The service will return the whole matching list.

There would be 2 entry points:

  • Minimal. Results will contain only beach Ids. Clients must have downloaded the json Beach List
  • Detailed. Results will contain all information I have about the beaches.

The weather report will be downloaded from a free on-line weather service like OpenWeatherMap. All dependencies will be abstract and constructor injected.

public IEnumerable<BeachMin> SearchMin(SearchRequest request) {
	var candidates = beachDal.GetBeachesMatching(

	var beachesWithWeatherReport = candidates
		.Select(x => new {
			Beach = x,
			Weather = weather.Get(x.Locality);

	var filteredBeaches = beachesWithWeatherReport
		.Where(x => x.Weather.Wind == request.Weather.Wind)
		.Where(x => (x.Weather.Sky & request.Weather.Sky) == request.Weather.Sky)
		.Select(x => x.Beach);

	var orderedByPopularity = filteredBeaches
		.OrderBy(x => x.Popularity);

	return orderedByPopularity
		.Select(x => x.TranslateTo<BeachMin>());

This is very simple and might look as good code. But hidden in this few lines is a single responsibility principle violation. Here I'm fetching data from a DAL and from an external service, filtering, ordering and finally transforming data. There are five reasons of change for this code. This might look OK today but problems will come later, as code ages.

Let's feed it some junk food

In any actual production scenario, this service will need some additions. Logging, to see what is going on and get some nice looking graphs; Cache to make it more efficient, and some Debug information to help us exterminate infestations. Where would all these behaviors go? To the business, of course. Nobody likes to put anything that is not database specific into the DAL. The web service itself does not have access to what is really going on. So...everything else goes to the BLL. This might look a little exaggerated, but believe's not.

public IEnumerable<BeachMin> SearchMin(SearchRequest request) {

	Debug.WriteLine("Entering SearchMin");

	var stopwatch = new Stopwatch();

	Logger.Log("SearchMin.Request", request);	

	Debug.WriteLine("Before calling DAL: {0}", stopwatch.Elapsed);
	var cacheKey = CreateCacheKey(request);
	var candidates = Cache.Contains(cacheKey)
		? Cache.Get(cacheKey)
		: beachDal.GetBeachesMatching(request.Location, request.TypeOfSand, request.Features);
	Cache.Set(cacheKey, candidates);
	Debug.WriteLine("After calling DAL: {0}", stopwatch.Elapsed);

	Logger.Log("SearchMin.Candidates", candidates);	
	Debug.WriteLine("Before calling weather service: {0}", stopwatch.Elapsed);
	var beachesWithWeatherReport = candidates
	.Select(x => new {
		Beach = x,
		Weather = weather.Get(x.Locality);
	Debug.WriteLine("After calling weather service: {0}", stopwatch.Elapsed);
	Logger.Log("SearchMin.Weather", beachesWithWeatherReport);
	Debug.WriteLine("Before filtering: {0}", stopwatch.Elapsed);
	var filteredBeaches = beachesWithWeatherReport
		.Where(x => x.Weather.Wind == request.Weather.Wind)
		.Where(x => (x.Weather.Sky & request.Weather.Sky) == request.Weather.Sky)
		.Select(x => x.Beach);
	Debug.WriteLine("After filtering: {1}", stopwatch.Elapsed);

	Logger.Log("SearchMin.Filtered", filteredBeaches);

	Debug.WriteLine("Before ordering by popularity: {0}", stopwatch.Elapsed);
	var orderedByPopularity = filteredBeaches
		.OrderBy(x => x.Popularity);
	Debug.WriteLine("After ordering by popularity: {0}", stopwatch.Elapsed);

	Debug.WriteLine("Exiting SearchMin");

	return orderedByPopularity;

If you don't own any code like previous: Bravo!! lucky you. I have written way too many BLLs that look just like this one. Now, ask yourself: What, exactly, does a "Paradise beach service" have to do with logging, caching and debugging? Easy answer: Absolutely nothing.

Usually there would be anything wrong with this code. But every application needs maintenance. With time, business requirements will change and I would need to touch it. Then a bug will be found: touch it again. At some point the monster will wake up and there would be no more good news from that point forward.

Actual business logic

Let's see what I'm actually doing:

  1. Find candidate beaches. Those in specified province with wanted features and type of sand.
  2. Get weather report about each of the candidates.
  3. Filter out those beaches not matching desired weather.
  4. Order by popularity.
  5. Transform the data into expected output.

This is how you would do it manually with a map and maybe a telephone and a patient operator to get the weather reports. This is exactly what a BLL must do, and nothing else.

I will implement a BLL for each of previous steps, they will have just one Execute method with one argument and a return value. Each step will have a meaningful intention revealing name that will receive an argument with the same name ended with Input and return type with the same name ended with Output. Conventions rock!!

public class FindCandidates : IFindCandidates
	private readonly IBeachesDal beachesDal;
	public FindCandidates(IBeachesDal beachesDal)
		this.beachesDal = beachesDal;

	public FindCandidatesOutput Execute(FindCandidatesInput input)
		var beaches = beachesDal.GetCandidateBeaches(

		return new FindCandidatesOutput
			Beaches = beaches

public class GetWeatherReport : IGetWeatherReport
	private readonly IWeatherService weather;

	public GetWeatherReport(IWeatherService weather)
	{ = weather;

	public GetWeatherReportOutput Execute(GetWeatherReportInput input)
		var beachesWithWeather = input.Beaches

		return new GetWeatherReportOutput
			BeachesWithWeather = beachesWithWeather

	private CandidateBeachWithWeather NewCandidateBeachWithWeather(CandidateBeach x)
		var result = x.TranslateTo<CandidateBeachWithWeather>();
		result.Weather = weather.Get(x.Locality);

		return result;

public class FilterByWeather : IFilterByWeather
	public FilterByWeatherOutput Execute(FilterByWeatherInput input)
		var filtered = input.BeachesWithWeather
			.Where(x => x.Weather.Sky == input.Sky)
			.Where(x => input.MinTemperature <= x.Weather.Temperature 
				&& x.Weather.Temperature <= input.MaxTemperature)
			.Where(x => input.MinWindSpeed <= x.Weather.WindSpeed 
				&& x.Weather.WindSpeed <= input.MaxWindSpeed);
		return new FilterByWeatherOutput
			Beaches = filtered

public class OrderByPopularity : IOrderByPopularity
	public OrderByPopularityOutput Execute(OrderByPopularityInput input)
		var orderedByPopularity = input.Beaches.OrderBy(x => x.Popularity);

		return new OrderByPopularityOutput
			Beaches = orderedByPopularity

public class TranslateToBeachMin : IConvertToMinResult
	public TranslateToBeachMinOutput Execute(TranslateToBeachMinInput input)
		return new TranslateToBeachMinOutput
			Beaches = input.Beaches
				.Select(x => x.TranslateTo<BeachMin>())

I know what you're thinking: I took a 15 lines of code (LOC) program and transformed it into a 100 or more one...You are right. But let's see what I have. Five clean and small BLLs, each represent a part of our previous single BLL. Their dependencies are abstract which will also make easy to test them thoroughly. They are easily to manage, because they are so small, they will be very easy to maintain, substitute and even reuse. For instance you don't really need to have performed a life weather search to get a list of beaches and weather conditions to be filtered, you just need to create the input for each of the steps and voilà, you can execute that particular step. At the end I added a step to translate CandidateBeach into BeachMin which is the response I really need for our original service. I also extracted interfaces for each of the steps, it helps with abstractions and some other things I'll do later.

Chain'em up

public IEnumerable<BeachMin> SearchMin(SearchRequest request) {
	var candidates = findCandidates.Execute(new FindCandidatesInput {
		Province = request.Province,
		TypeOfSand = request.TypeOfSand,
		Features = request.Features

	var candidatesWithWeather = getWeatherReport.Execute(new GetWeatherReportInput {
		Beaches = candidates.Beaches

	var filtered = filterByWeather.Execute(new FilterByWeatherInput {
		Beaches = candidates.Beaches,
		Sky = request.Sky,
		MinTemperature = request.MinTemperature,

		MaxTemperature = request.MaxTemperature,
		MinWindSpeed = request.MinWindSpeed,

		MaxWindSpeed = request.MaxWindSpeed

	var orderedByPopularity = orderByPopularity.Execute(new OrderByPopularityInput {
		Beaches = filtered.Beaches

	var result = translateToBeachMin.Execute(new TranslateToBeachMinInput {
		Beaches = orderedByPopularity.Beaches

	return result;

What do you know? I'm back to 15 LOC, maybe less. I think this code doesn't even need explaining. I took our steps and chain them into a Behavior Chain. From now on we will refer to Steps as Behaviors. I'm kind of where I started, but now our service depends on external extensible, reusable and abstract behaviors. Still, it must know them all. This makes difficult adding a new behavior. Another thing I will have almost identical code for the other entry point. I must do something to improve these two.

Mechanize it

I know...Sarah Connor wouldn't agree. I have this tool which takes some objects and automatically chains them together into a function but before let's see what a service depending on functions would look like.

public class SearchService : Service {
	public SearchService(
		Func<SearchMinRequest, SearchMinResponse> searchMin,
		Func<SearchDetailsRequest, SearchDetailsResponse> searchDetails) {
			this.searchMin = searchMin;
			this.searchDetails = searchDetails;
	public object Any(SearchMinRequest request) {
		return searchMin(request);
	public object Any(SearchDetailsRequest request) {
		return searchDetails(request);

I'm using ServiceStack as web framework. Basically both Any method in the examples are web service entry points. As you can see they delegate the actual work to functions injected thru the constructor. At some point, which for ServiceStack is the application configuration, I need to create these functions and register them into the IoC container.

public override void Configure(Container container) {
	var searchMin = Chain<SearchMinRequest, SearchMinResponse>(
	var searchDetails = Chain<SearchDetailsRequest, SearchDetailsResponse>(

private static Func<TInput, TOutput> Chain<TInput, TOutput>(params object[] behaviors) 
	where TInput : new() 
	where TOutput : new() 
	return behaviors
		.Chain<TInput, TOutput>();

There are some points here that is worth mentioning:

  • Each behavior kind of depends on previous but it doesn't really know it
  • The chain is created from functions which could be instance or static methods, lambda expressions or even functions defined in another language like F#
  • The ExtracBehaviorFunctions method takes in objects and extracts their Execute method or throw an exception if there is none. This is my convention, you could define your own
  • The Chain method takes in delegates and creates a function by chaining them together. It will throw exceptions if incompatible delegates are used


I will enrich our BLLs by means of transparent decorators. Using Castle.DynamicProxy I will generate types which will intercept the calls to our behaviors and add some features. Then I will register the decorated instances instead of the original. I will start with cache and debugging. The cache is a trivial in memory, 10 min. More complicated solutions can be easily implemented.

container.Register(new ProxyGenerator());

container.Register<ICache>(new InMemory10MinCache());

CacheDecoratorGenerator = container.Resolve<CacheDecoratorGenerator>();

DebugDecoratorGenerator = container.Resolve<DebugDecoratorGenerator>();

With this code our decorator generators are ready, let's look now on how to decorate the behaviors.


var findCandidates = DebugDecoratorGenerator.Generate(

var getWeatherReport = DebugDecoratorGenerator.Generate(

var filterByWeather = DebugDecoratorGenerator.Generate(

var orderByPopularity = DebugDecoratorGenerator.Generate(

var convertToMinResult = DebugDecoratorGenerator.Generate(

Here I decorated every behavior with debugging and only findCandidates with caching too. It might be interesting to add some cache to weather report as well, but since the input might be a very big list of beaches caching won't be correct. Instead I will add caching to both the DAL and the weather service.

container.Register(c => DebugDecoratorGenerator.Generate(
        (IBeachesDal) new BeachesDal(c.Resolve<Func<IDbConnection>>()))));

container.Register(c => DebugDecoratorGenerator.Generate(
        (IWeatherService) new WeatherService())));

Manual Decorators

Generated decorators are not enough for some tasks, and if you are friend of IDE Debugging they will certainly give you some headaches. There is always the manual choice.

public class FindCandidatesLogDecorator : IFindCandidates
	private readonly ILog log;
	private readonly IFindCandidates inner;

	public FindCandidatesLogDecorator(ILog log, IFindCandidates inner)
		this.log = log;
		this.inner = inner;

	public FindCandidatesOutput Execute(FindCandidatesInput input)
		var result = inner.Execute(input);
		log.InfoFormat("Execute({0}) returned {1}", input.ToJson(), result.ToJson());

		return result;

By using more powerful IoC containers, like AutoFac you would be able to create more powerful decorators, both automatically generated and manual. You won't ever have to touch your BLL unless there are Business Requirement changes or bugs.

When to use

When your BLL is a set of steps that are:

  • Well defined. The responsibilities are clear and have clear boundaries.
  • Independent. The steps don't know each other.
  • Sequential. The order cannot be changed based on input. All steps must be always executed.

The behavior chain functions are kind of static, they are not meant to be altered in execution. You can create, though, a new function to replace an existing one based on any logic of your specific problem.

How it works

The generation code isn't really that interesting. Just a lot of hairy statements generating lambda expressions using the wonderful Linq.Expressions. You can still look at it on the source code. Let's see instead how generated code works. This is how the generate function looks like, or kind of.

var generatedFunction = new Func<SearchDetailsRequest, SearchDetailsResponse>(req => {
    // Input
    var valuesSoFar = new Dictionary<string, object>();
    valuesSoFar["Provice"] = req.Provice;
    valuesSoFar["TypeOfSand"] = req.TypeOfSand;
    valuesSoFar["Features"] = req.Features;
    valuesSoFar["Sky"] = req.Sky;
    valuesSoFar["MinTemperature"] = req.MinTemperature;
    valuesSoFar["MaxTemperature"] = req.MaxTemperature;
    valuesSoFar["MinWindSpeed"] = req.MinWindSpeed;
    valuesSoFar["MaxWindSpeed"] = req.MaxWindSpeed;

    // Behavior0: Find candidates
    var input0 = new FindCandidatesInput {
        Provice = (string)valuesSoFar["Provice"],
        TypeOfSand = (TypeOfSand)valuesSoFar["TypeOfSand"],
        Features = (Features)valuesSoFar["Features"]
    var output0 = behavior0(input0);
    valuesSoFar["Beaches"] = output0.Beaches;

    // Behavior1: Get weather report
    var input1 = new GetWeatherReportInput {
        Beaches = (IEnumerable<CandidateBeach>)valuesSoFar["Beaches"]
    var output1 = behavior1(input1);
    valuesSoFar["Beaches"] = output1.Beaches;

    // Behavior2: Filter by weather
    var input2 = new FilterByWeather {
        Beaches = (IEnumerable<CandidateBeachWithWeather>)valuesSoFar["Beaches"]
        Sky = (Sky)valuesSoFar["Sky"],
        MinTemperature = (float)valuesSoFar["MinTemperature"],
        MaxTemperature = (float)valuesSoFar["MaxTemperature"],
        MinWindSpeed = (float)valuesSoFar["MinWindSpeed"],
        MaxWindSpeed = (float)valuesSoFar["MaxWindSpeed"]
    var output2 = behavior2(input2);
    valuesSoFar["Beaches"] = output2.Beaches;

    // Behavior3: Order by popularity
    var input3 = new OrderByPopularityInput {
        Beaches = (IEnumerable<CandidateBeach>)valuesSoFar["Beaches"]
    var output3 = behavior3(input3);
    valuesSoFar["Beaches"] = output3.Beaches;

    // Behavior4: addDetails
    var input4 = new AddDetailsInput {
        Beaches = (IEnumerable<CandidateBeach>)valuesSoFar["Beaches"]
    var output4 = behavior4(input4);
    valuesSoFar["Beaches"] = output4.Beaches;

    // Output
    return new SearchDetailsResponse {
         Beaches = (IEnumerable<BeachDetails>)valuesSoFar["Beaches"]

Using the code

What is it good for if you cannot see it working?

This will start the server in configured port, 52451 by default. Now you need to create a client program. You can manually create a client project by using ServiceStack. Or any other web framework. You can also use included Linqpad file at <project_root>\linqpad\search_for_beaches.linq which basically does as follows:

var client = new JsonServiceClient("http://localhost:52451/");
var response = client.Post(new SearchDetailedRequest {
    Province = "Huelva",
    Features = Features.Surf,
    MinTemperature = 0f,
    MaxTemperature = 90f,
    MinWindSpeed = 0f,
    MaxWindSpeed = 90f,
    TypeOfSand = TypeOfSand.White,
    Sky = Sky.Clear


The high code quality is very important if you want a maintainable application with a long lifespan. By choosing the right design patterns and applying some techniques and best practices any tool will work for us and produce really elegant solutions to our problems. If on the other hand, you learn just how to use the tools, you are gonna end up programming for the tools and not for the ones that sign your pay-checks.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Erich Ledesma
Architect SunHotels
Spain Spain
I Received a Bachelor's Degree in Computer Science at the Mathematics and Computer Science Faculty, University of Havana, Cuba.

I mainly work in web applications using C# and some Javascript. Some very few times do some Java.

You may also be interested in...

Comments and Discussions

GeneralMy vote of 5 Pin
abdurahman ibn hattab10-Sep-14 10:21
memberabdurahman ibn hattab10-Sep-14 10:21 
GeneralRe: My vote of 5 Pin
Erich Ledesma10-Sep-14 11:07
memberErich Ledesma10-Sep-14 11:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.171114.1 | Last Updated 9 Sep 2014
Article Copyright 2014 by Erich Ledesma
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid