WAQS: Introduction

7 reasons to use WAQS

WAQS documentation


I’m very happy to announce that a beta of WAQS is now available on NuGet.


I decided to write many posts to explain how to use WAQS and also the different challenges I fixed to develop WAQS.

I will write two kinds of posts: some posts with titles starting by “How to” to explain how to use WAQS and some others starting by “how does WAQS” or “Why does WAQS” to explain how WAQS works.

So, in next months, I will write about many technologies such as T4, Roslyn, NuGet, Entity Framework, LINQ, PowerShell, VS, MS IL, WCF, Unity, Rx, etc.


But before talking about all of this, I wanted to start with an introduction to explain what is WAQS.


WAQS is a Framework very useful to speed up development of .Net data centric distributed applications.

More clearly, WAQS is a Framework generator. In this sense, it’s better to say that it’s a « meta Framework ». Indeed, WAQS massively uses meta-programming, using intensively T4 templates, Roslyn and NuGet, in order to build a framework fitted with your domain.

WAQS gives you a better productivity with excellent performances, taking in charge technical aspect using well-tried patterns, as well as flexibility and a robust code for your business rules implementation. In this last point, WAQS approach is an efficient alternative, or why not a supplement, to DDD conception.

You have the choice with WAQS: you can use specific parts or you can use it for all the layers of the application. WAQS is an “Opinionated Framework”: it makes some choices but let the flexibility of your architecture choices.

The WAQS (WCF Async Queryable Services) initial idea was to reproduce Entity Framework ObjectContext features on the client, so having the flexibility and the powerful of remotely querying your data and having a transparent changes tracking in order to be able to persist them, later, in one transaction without thinking about it.

Microsoft tried to solve this with WCF Data Services and WCF RIA Services but these Frameworks have a lot of restrictions that are often crippling.

Comparing to these initiatives and also comparing to Entity Framework, WAQS extends possibilities instead of reducing them and Jacob Reimers wrote on twitter "WAQS is remote EF on steroids".

Today, WAQS has evolved into a more comprehensive code generation solution that abstracts away the technical code in order to let developers focus on value add tasks: screens and business code and Jacob tweeted "WAQS adds the abstraction future languages will have. IMO, the gap from C# to C#+WAQS is like the one from IL to C#". Even if I think it’s too much, I agree with him: Roslyn can be used to add a lot of abstraction in order to improve the way developers work today and WAQS does it.

To resume, WAQS proposes:

  • Querying from the client with an asynchronous way,
  • Changes transparent tracking and persistence of them,
  • A solution to avoid « spaghetti » code and code duplication, particularly for business code,
  • Simplifies MVVM.

With a manager point of view, WAQS allows:

  • To industrialize and homogenize development process with a flexible and customizable solution,
  • To improve a lot team productivity,
  • To increase reliability and improve maintainability of the solution,
  • To reduce risks and costs.

And this is possible

  • Without fundamentally change developer habits, WAQS having been thought for them,
  • Without using a private tool or engine. WAQS only generates some code in the solution just using Microsoft tools in order to ensure the maximum of durability and reducing the risk.
This entry was posted in 16868, 17895. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *