Builder Design Pattern Update

DZone 's Guide to

Builder Design Pattern Update

Recently, a reader made me aware of some old code. Today, in this post, we revise our Builder Design Pattern with an updated library.

· Web Dev Zone ·
Free Resource

Three years ago, I wrote how to create a filter using a Builder design pattern and passing that expression into a query to return results.

This post was production code and is currently providing search results as we speak.

In the post, I also mentioned using the PredicateBuilder from the C# in a Nutshell book.

While this PredicateBuilder is now included in the LinqKit library, one reader (Thanks, Kevin!) made me aware that the syntax was deprecated and provided me with an update.

LinqKit Example

Once you include this library, the updated syntax should look similar, as we only need to replace one line.

In the Build method, I had:

public Expression<Func<Product, bool>> Build()
    // old and busted
    var predicate = new Expression<Func<Product, bool>>();

Now, our updated version is a little more modern.

public Expression<Func<Product, bool>> Build()
    // new hotness
    var predicate = PredicateBuilder.New<Product>(true);

Once you make this change, your AndAlso methods should light up as well. Replace the AndAlso's with .And. The syntax should work the same.

Everything should function as normal.

Bonus: Ed Charbeneau's PredicateExtensions

After watching Ed at Codemash 2018 with his session on Going All in With Functional C#, he demonstrated how powerful functional programming can be with C# by playing cards (you'll just have to go next time).

He also released a PredicateExtensions library as well.

His syntax is just as easy. Include his library, and the syntax becomes:

public Expression<Func<Product, bool>> Build()
    // Search Term
    var predicate = PredicateExtensions.PredicateExtensions.Begin<Product>();

For more on how to extend expressions, I urge you to check out his post on Giving Clarity to LINQ Queries by Extending Expressions.


The best part about design patterns is that they provide solid solutions to common code problems.

As I mentioned above, the builder design pattern post was written three years ago. I've used this design pattern numerous times since then.

This is why it's best to learn design patterns. Once you understand and implement a design pattern, it will immediately give you dividends throughout your career.

While libraries and frameworks may change over the years, design patterns are the concepts that stand the test of time no matter what language you use.

Which this post just proved.


Have you implemented this design pattern in your code? Did you have to modify it? What changes did you make? Post your comments below and let's discuss.

c#, design pattern, refactoring, web dev

Published at DZone with permission of Jonathan Danylko , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}