If, numerous technologies or products were invented by research, WAQS is the result of a “real world” work.
WAQS development was managed by needs of real applications today in production and each feature is an answer to a concrete issue we often need to fix.
Many years as consultant allows me to identify frequent issues and traps developers can fall in, with EF on top of them.
More and more projects need to release quick, companies must be reactive and reduce development cost.
In this context, it is hard to justify the usage of such and such technical infrastructure component which has been coded and coded again for each application.
It is hard to justify some standard frameworks limitations for something that does not even seem unreasonable.
It is hard to justify the usage of such and such complex architecture that many developers don’t understand.
WAQS is not usable for any project or any context but WAQS is pragmatic: it helps you to quickly release a clean and reliable application.
The main goal is to be concentrated on screens and business logic and WAQS brings the abstraction that lets you ignoring technical complexity.
Indeed, WAQS was thought to hide to developers technical complexity and let them focus on their features.
In this way, even with its features wealth, experience demonstrates that WAQS learning curve is very reasonable.
WAQS approach, particularly thank to convention usage, makes homogeneous applications, controllable and mechanizable, on which it’s easy to be operational very quickly.