Project Description
Teaq is an object-relational mapping framework that provides composable functionality to aid query generation, query batching, and object materialization.

The Teaq binaries are hosted at For package information, see:

If you staying on latest, and will likely upgrade from version 1.4 to 2.0, there are some breaking changes of which to be aware. The latest sources reflect 2.0 changes, and 2.0 will be available via the NuGet feed in Q4, pending additional performance tuning and functional testing.

Teaq offers a means to arbitrarily map classes to relational data. The design of this API allows for using its parts in any combination. You can opt to use fluent query comprehension with expressions, object materialization, and query batching together, or independently.

Teaq does express a few design opinions regarding how data access is done, in part as a reaction to real production performance and anti-pattern design issues using Entity Framework (v5):
  1. Complex queries should be written using SQL.
  2. Object materialization should be fast by default and work by convention
  3. Developers should be able to inject explicit mapping code for very hot path scenarios and still use the other areas of the Teaq framework as designed.
  4. Object hierarchies often vary by use case and condition, and therefore should not be described as if this is a design time problem. Let developers decide the appropriate mix of ORM and in-memory hierarchy logic. To help these use cases, enable developers to batch queries to minimize DB round trips, and expose an API such that multiple result sets are easy to work with.
  5. O(n) data access patterns are evil and should not be hidden; you as a developer should be able to see query execution clearly in code.
  6. The database should not be viewed as a domain state machine; real-world applications often have complex data access patterns and functional behaviors that don't always translate easily into "a collection of entities".
  7. Pluggable data providers are cool, but in practice, teams tend to fix themselves on a single RDBMS and focus their skills accordingly. Teaq focuses on integrating SQL Server and doesn't bother with abstracting for different underlying data stores.
On the last point above, the underlying ADO.NET API's do offer some abstractions, and these abstractions are used to improve the internal testability of the framework, but there is no design intent to fully support and test for other ADO.NET providers at this time. This might be an interesting area for future contribution.

See the Documentation page for a design overview and usages.

Last edited Jul 18, 2016 at 11:46 AM by bkjuice, version 22