Data and Business Layer, the New Way

Existing Patterns

• Transaction Script and Domain Model: The business logic is placed in-memory code and the database is used pretty much as a storage mechanism.
• Logic in SQL: Business logic is placed in SQL queries such as stored procedure.

The Misconceptions

SQL is Obsolete

All non-trivial abstractions, to some degree, are leaky.

OOP/POCO Obsession

1. To serialize/deserialize an object, a converter for the reference is needed, either implicitly or explicitly. ORM can be considered as the converter between objects and relational data.
2. As the object complexity grows, the complexity of the converter grows respectively. Particularly, the type metadata and compiled byte code (the behavior of the object, or the logic), are difficult or maybe impossible for the conversion - in the end, you need virtually the whole type runtime. That's why so many applications start with Domain Drive Design, but end up with Anemic Domain Model.
3. On the other hand, relational data model is very complex by nature, compares to other data format such as JSON. This adds another complexity to the converter. ORM, which is considered as the converter between objects and relational data, will sooner of later hit the wall.

The New Way

• Model/Model<T>: Defines the meta data of model, and declarative business logic such as data constraints, automatic calculated field and validation, which can be consumed for both database and local in-memory code.
• DataSet<T>: Stores hierarchical data locally and acts as domain model of your business logic. It can be conveniently exchanged with relational database in set-based operations (CRUD), or external system via JSON.
• Db: Defines the database session, which contains:
  • DbTable<T>: Permanent database tables for data storage;
  • Instance methods of Db class to implement procedural business logic, using DataSet<T> objects as input/output. The business logic can be simple CRUD operations, or complex operation such as MRP calculation:
    • You can use DbQuery<T> objects to encapsulate data as reusable view, and/or temporary DbTable<T> objects to store intermediate result, to write stored procedure alike, set-based operations (CRUD) business logic.
    • On the other hand, DataSet<T> objects, in addition to be used as input/output of your procedural business logic, can also be used to write in-memory code to implement your business logic locally.
    • Since these objects are database agnostic, you can easily port your business logic into different relational databases.
• DbMock<T>: Easily mock the database in an isolated, known state for testing.