USP

How is Agile Data different?

We have made same big claims saying that Agile Data is better and more suitable for your application logic and performance than established ORM, ActiveRecord and Query Builder libraries.

In this section I will give you some practical comparisons focusing on reviewing design patterns used in the industry and highlight how Agile Toolkit is equipped to deal with them.

Separtion of Persistance Domain and Persistance

There are several articles that explain the problem very well:

• ORM Anti-Patterns - Part 4: Persistance Domain Model

More particularly, the problems of Mapping are explained here:

• Object-Relational Impedance Mismatch

TL;DR - Your logical entities and database tables are different making some of techniques - "hard to use":

• Object Oriented Patterns (Encapssulation, Inheritance, Polymorphism)
• Relational Concept
• Data Type differences
• Structural and Integrity differences

The current solutions involve:

• Dumbing down RDBMS / ObjectOriented features to achieve Minimization (Active Record)
• Code-generation to map relations into object-oriented world
• Alternatively - Avoiding ORM/AR entirely with manual Query Building.

As a result, you get a very primitive and inefficient way to interact with your database and a separate engine to create and execute custom queries.

In case of PHP, both patterns are linking "persistence" layer into your models. Often models are generated/baked into your PHP code by examining your database. Developers are not educated how to create "Domain Model" because SQL-First is the common design pattern.

• https://www.sitepoint.com/community/t/domain-model-anemic-domain-model-and-single-responsibility-rule/35193/2

See also this article on building a Domain Model and how verbose is the approach when frameworks are not involved. The article does not implement any MySQL bindings still.

For most of data access layers one of the two is true: Anemic Domain Model

What approach we used in Agile Data

We focus on Object Oriented design to present all the business classes as intended inside your Domain Model. We offer you the "abstract entitiy" implementation that is capable of:

• creating outline of your models
• applying validation and business
• adding logic into methods
• storing meta-information about fields

Your general entity rules are defined as class but you should also be able to operate on record level, so we add more features:

• manipulate row data
• good understanding of "id" and "source" of the data.

With this you can describe your Data Models in a much more consise way.

Next, lets look at the problem with Anemic Domain Model. If you follow the design correctly, then your at performing vendor-specific operations should go inside Service Layer, so most functionality ends up there.

In Agile Data you can write your business logic in a very expressive way that does not rely on Database implementation and does belong in the Domain Model.

2. Persisting, Associations and Criteria

When it comes to implementation of Persistence, the existing implementation such as Doctrine offer a very complex and incomplete ways to deal with mapping. Why is it incomplete? Because following some patterns result in performance issues and limitations.

• https://tideways.io/profiler/blog/5-doctrine-orm-performance-traps-you-should-avoid
• http://mnapoli.fr/collection-interface-and-database-abstraction/

What about those other ORM and Frameworks? I don't think they're good at DDD. They solve problems in a practical way, the "Conclusion" by Chris is still actual today:

• http://fideloper.com/how-we-code

In my opinion the complex way of Doctrine approach is hard to learn for PHP developers who look for simple, clever and practical solutions.

The other problem is with record limiting that have been sort of a "patchwork" throughough the frameworks:

• Laravel scopes
• Doctrine Criteria
• DJango QuerySet and SoftDelete

Agile Data use of DSQL and DataSets

Developers need ability to work with "sub-set" of records. Not only querying but also adding and modifying them. This is one of the fundamental concepts in Agile Data called "DataSets". (this has nothing in common with dataset in .NET).

DataSet is basically a way to translate your Business Model into a Query with some conditions applied.

• Each business model has data-set
• When extending business model, you can narrow down data-set
• Works perfectly with joins

DataSet lives in your Domain Model. That means that any operation that you can implement through DataSets can be perfectly fine inside your Business Model.

DataSet concept is perfect when you think about relations between various business models. In a way "DataSet" is SQL Query-in-progress, as it hasn't been executed yet, however it's expressed in the Domain Model terms of business entities and therefore is perfect for expressing complex business logic rules.

Agile Data builds it's implementation around DSQL where all the queries are built with the advanced query bulider and DataSet is a natural extension for that. While most Query Builders are strictly operate with "tables" and live in Presentation Logic - for Agile Data - Query builder is a glue of two realms.

• Build Any Query
• Use Domain Model logic
• Works with read and write.

DataSets are different because you can also write records into them. You can also derive queries out of it. The more you think about it - the more you will realise how powerful is the concept.

But what's most important, is how simple the concept is for new users. It takes a fraction of time one would take to learn Doctrine yet you will be expressing your domain model through sub-queries in no-time.

Unit Testing vs Integration Testing

The practicality of PHP leads most of developers to think in terms of "integrated functionality". When it comes to Unit Tests, most PHP apps written in frameworks will have difficulties as the won't follow Domain Driven Design.

With Agile Data you can create Unit Tests by creating entirely different Persistence layer and mocking how your Business Model work without your actual database connection.