Let's say you have a domain with two types of Workers: Contractor and Employee. It's the role of a Repository to map between domain objects and the data model, so we'd like to have our repository enabling us to retrieve a Contractor or an Employee from the database.
A data model that would support this domain in a document database (the only kind currently supported by Liquid) would be to have a single collection named Workers that would contain both type of workers. Now, let alone the fact that since Repository isn't customizable we wouldn't be able to have it return either class given a rule. This is bad, but let's say we have our users always inform us whether we are operating on Contractors or Employees; that would overcome the main mapping limitation but we could correctly inform Repository which objects we are looking for.
That wouldn't work, because Liquid uses the class name to determine which collection we are using. So when we say Repository.Get<Contractor>(...) Liquid is looking at "Contractor" collection, while when we say Repository.Get<Employee>(...), Liquid is looking "Employee" collection.
This hard limit imposes a lot on the data structure of our application - for instance, we would need to have two collections.
Let's say you have a domain with two types of
Workers:ContractorandEmployee. It's the role of a Repository to map between domain objects and the data model, so we'd like to have our repository enabling us to retrieve a Contractor or an Employee from the database.A data model that would support this domain in a document database (the only kind currently supported by Liquid) would be to have a single collection named Workers that would contain both type of workers. Now, let alone the fact that since Repository isn't customizable we wouldn't be able to have it return either class given a rule. This is bad, but let's say we have our users always inform us whether we are operating on
Contractors orEmployees; that would overcome the main mapping limitation but we could correctly inform Repository which objects we are looking for.That wouldn't work, because Liquid uses the class name to determine which collection we are using. So when we say
Repository.Get<Contractor>(...)Liquid is looking at "Contractor" collection, while when we sayRepository.Get<Employee>(...), Liquid is looking "Employee" collection.This hard limit imposes a lot on the data structure of our application - for instance, we would need to have two collections.