The Repository is a design pattern, which helps to load data from the database providing abstract API, concealing the storage implementation details.

The Query Object pattern enables the creation of declarative queries adaptable to different database (or any storage) implementations.

Combination of these two patterns creates a robust API for loading domain objects from external source, obscuring the implementation details while providing declarative querying interface.

## **Terms and Concepts**

- Abstract API - a programming interface, which is decoupled or loosely coupled to the implementation. Defining Abstract API over the implementation allows to conceal the implementation details.

- Declarative query - query which is created by saying what to find, instead of how to find.

- Domain objects - refers to the object, which is a part of a domain, not a random object in the system Domain objects are always persisted to a database. Repository pattern the abstracts database from the runtime domain objects.

This is the quote from his book:

> Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.Martin fowler

## **Chart Description**

Chart below is a UML class diagram. It depicts how the Repository and Query Objects patterns can be used together. I'm omitting the ORM in this diagram on purpose, not to over-complicate it.

- Repository is an abstract interface with one method that loads items by criteria(Query Object) and returns collection like domain objects. This is the main point of mapping, loading and caching domain objects.

- ItemRepository implements Repository interface. It uses ItemCriteria to load Items

- ItemLoadStrategy - strategy(GoF) that allows having different loading implementations of data loading. It may be database or in-memory object storage for testing. This interface obscuring the implementation of storage, letting to use predefined implementations, or implement custom.

- ItemCriteria - is a Query Object, which is used to create declarative query. In this implementation Query Object is anemic. It does not have any behavior. It just provides API to create queries. Each loading strategy implementation will interpret the Query Object and convert to implementation specific query. In case storage is relational database, query object may construct SQL query with a help of metadata mapping class (ItemMetadataColumn).

- ItemMetadataColumn - describes "columns" in the database. Though the implementation of storage is unknown, each property is contained in this enum, acting as a MetadataMapper pattern element from Martin Fowlers patterns.

_Patterns of Enterprise Application Architecture: Martin Fowler, with Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford_

_Note: The content in this article is a summary/interpretation inspired by them. Proper attribution is given to the respective authors._

## **Real life Example: TypeORM**

TypeORM is popular TypeScript ORM library. This library uses Repository and Query Object patterns. This is quote from the documentation [typeorm.io/select-query-builder#what-is-querybuilder](https://typeorm.io/select-query-builder#what-is-querybuilder)

> QueryBuilder is one of the most powerful features of TypeORM - it allows you to build SQL queries using elegant and convenient syntax, execute them and get automatically transformed entities. Simple example of QueryBuilder:

```javascript
const firstUser = await dataSource
    .getRepository(User)
    .createQueryBuilder("user")
    .where("user.id = :id", { id: 1 })
    .getOne()
```

> It builds the following SQL query:

```plain text
SELECT
    user.id as userId,
    user.firstName as userFirstName,
    user.lastName as userLastName
FROM users user
WHERE user.id = 1
and returns you an instance of User:
```

## **Real life Example: Hibernate**

Hibernate is popular ORM mapping library in Java ecosystem [Hibernate_Introduction.html#queries](https://docs.jboss.org/hibernate/orm/6.4/introduction/html_single/Hibernate_Introduction.html#queries). Hibernate utilizes Query Object pattern and took another path, and do not use Repository. Instead Query Object can create query and call database with converted query:

> Is the Queries interface starting to look a lot like a DAO-style repository object? Well, perhaps. You can certainly decide to use this facility to create a BookRepository if that’s what you prefer.

```java
// create criteria builder
HibernateCriteriaBuilder builder =
        (HibernateCriteriaBuilder) entityManagerFactory.getCriteriaBuilder();
```

We’re ready to create a criteria query.

```java
CriteriaQuery<Book> query = builder.createQuery(Book.class);
Root<Book> book = query.from(Book.class);
Predicate where = builder.conjunction();
if (titlePattern != null) {
    where = builder.and(where, builder.like(book.get(Book_.title), titlePattern));
}
if (namePattern != null) {
    Join<Book,Author> author = book.join(Book_.author);
    where = builder.and(where, builder.like(author.get(Author_.name), namePattern));
}
query.select(book).where(where)
    .orderBy(builder.asc(book.get(Book_.title)));
```

Repository and Query Object

Lazy load is a pattern to get data the data at the last moment, when it is actually required. This pattern is applied, when loading the data can have negative performance impact. One of the techniques to tackle this problem is pattern "Lazy load".

This is the quote from his book:

> An object that doesn't contain all of the data you need but knows how to get it.Martin fowler

Though Marting is describing the use-cases of using this pattern within the scope of interactions with the database, we can apply this pattern in other situations, where loading is expensive. For example resolve data in the UI via the REST API, if the payload is big, or if loading the full object may required the sophisticated graph of child objects to be resolved. If we do not need this data immediately, we can utilize lazy load pattern. This

This pattern has multiple implementations:

- **Lazy initialization** - this pattern pattern described first by a Kent Beck. Using this pattern allows to have object without all values. Values are resolved on demand in the "getter methods".

- **Virtual Proxy** - this pattern also allows object not to have all values. Proxy object lookups values in the real object, if values are absent "Proxy" knows how to resolve the values.

- **Value Holder** - it is a separate object from the value object. It holds the value or **`null`** If the value is absent, "Value Holder" knows how to load it. Use this pattern when you cannot use the partial data, or having the partial data is bigger overhead, than a simple value holder.

- **Object Ghost** - I do not like this pattern, and will not describe it intentionally here. In the Martin Fowler describes this pattern in detail in his book(referenced below).

Saving this value for later, is the same as caching in memory. Be aware that you need to think about the cache invalidation in case you are saving the value in memory.

These are code samples for all of the implementation described above:

```typescript
type Order = {}
const resolveOrders = () => [{}]


// Lazy initialization
class Customer {
    _orders: Order[]
    private resolveOrders: () => Order[]
    constructor(resolveOrders: () => Order[]) {
        this.resolveOrders = resolveOrders
    }

    get orders() {
        if(this._orders) return this.orders
        this._orders = this.resolveOrders()
        return this._orders
    }
}


const lazyInitCustomer = new Customer(resolveOrders)

// Virtual proxy
interface CustomerData {
    orders: Order[]
}

const proxyCustomer = new Proxy<CustomerData>({orders: undefined as any}, {
    get(target, p) {
        if (p === 'orders') {
            if(target.orders) return target.orders
            target.orders = resolveOrders()
            return target.orders
        }
    },
})

// Value holder
class ValueHolder<V> {
    private value: V | undefined
    private resolveValue: () => V

    constructor(resolveValue: () => V) {
        this.resolveValue = resolveValue
    }

    resolve(): V {
        if (this.value) return this.value
        this.value = this.resolveValue()
        return this.value
    }
}

const ordersHolder = new ValueHolder<Order[]>(resolveOrders)
```

_Patterns of Enterprise Application Architecture: Martin Fowler, with Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford_

_Note: The content in this article is a summary/interpretation inspired by them. Proper attribution is given to the respective authors._

Lazy Load

In the book Patterns of _Enterprise Application Architecture by Martin Fowler_ two patterns are defined to handle business logic in the system. I do not think that much have changed since then. The IT industry evolved, but these patterns are still applicable to this day. I will unpack what those patterns mean and how they are applicable now.

**Domain model** is a pattern where object representing the model also contains the behavior and/or business rules in itself.

- ✔️ data together with the behavior

- ✔️ easy to extend

- ✔️ easy to comprehend / observe if applied correctly

- ❌ requires more effort and experience to implement

- ❌ may be overhead for a simple domain

**Transaction script** is a pattern where a separate script/object/function/service loads the data validates/modifies it and saves to the database.

- ✔️ requires less effort and experience to implement

- ✔️ fits simple domain applications

- ❌ anemic model, which is considered as an anti-pattern by a Martin Fowler

- ❌ hard to maintain / extend / observe on a more complex domain

Both of these patterns are pretty abstract and can be applied today with other architectural and design patterns. Each of those has pros and cons. You can use these pattern in your server side rendered UI MVC application with, react server components, PHP or Java server pages.

## **Difference**

The difference between those patterns is complexity. Complexity of implementation, extensions and support. Domain model can harder to implement initially. But it reduces the complexity, when the model is evolving, getting more complex. Keeping business logic in one place with the domain reduces the complexity of extension and refactoring. On the other hand transaction script separates data from the behavior. At the start it is easier to model you data and write a transaction script to handle business rules. But this approach will not scale, with the size of your model and the domain complexity.

## **Challenges**

At the time _Martin Fowler wrote the book Patterns of Enterprise Application Architecture_ was written, the standard UI architecture was HTML rendered on server with a small amount of interactivity sprinkled by javascript. All logic could be handled by both patterns on the server. Mostly it is MVC pattern for a web server with a input controller acting as a mediator. Today the expectations of the UI/UX have changed. UI is way more interactive - UI applications handles routing, validation, data initialization and manipulation, UI flow management, security and whats not. Previously UI was not responsible for all those things. This is why implementing business logic in the maintainable manner is crucial for a modern UI application. Domain model is one of the options, which must be considered. If you will leave the majority of these concerns on the server, then UI will request those. Multiple requests will degrade the responsiveness of an application.

## **Examples**

For example consider case when you need to validate the 1mb json data. You have thousands of business rules, which must be evaluated, to ensure the data is valid. During the data gathering process you will make thousands REST API calls to the server to validate the data, to provide instant feedback on entered values. If you will choose to make validation once per tab/dropdown/card/step, then user will have a bunch of errors after he completed the step. This can be a tradeoff of keeping the logic on the backend and requesting this logic from the server.

- using transaction script you will end up with thousands of functions, with duplicated logic between those and the code which is hard to comprehend.

- using the domain model pattern your business rules will be "managed" together with the model. Rules will be kept with the domain which matches the Single responsibility principle.