Seedstack 中的 Repository 和 Finder 有什么区别？

Question

I'm Using Seedstack 16.7 and its Business framework with JPA plugin support.

There's 2 ways to acquire data from a datasource.

1. Repositories http://seedstack.org/docs/business/manual/repositories/

   • They are pretty much the ones that acts in behalf of an traditional EntityManager on JPA, keeping the type safety.

2. Finders http://seedstack.org/docs/business/manual/finders/

   • They retrieve Dto from a datasource.

The only apparent difference between them is that finder is a read only interface to a datasource.

Most of the queries that a finder requires can be done just by calling a repository and converting from a Aggregate to a Dto

Is there any real difference between them, or on their intended? other than stated on this question.

Answer 1

It is somewhat complex to explain it in a few lines because that modeling decission comes from deep understanding of DDD, CQ(R)S, fast readmodels, eventual consistency, etc.

• Finders

As the manual says: "Query the persistence layer or any data source to obtain objects specific to an interface of the application". The keyword here is Interface . In the case of a graphical UI the use of finders is to retrieve a concrete view to present it in a desktop form or webpage. In a non CRUD app the UI should be Task-Based so:

1. Your views does not match your Entities and Aggregates.
2. Your Entities and Aggregates does not (should not) contain the full lists of selection data ie: States and Cities (classic cascading dependency comboboxes)
3. Your Aggregates and Entities does not (should not) contain the full list of referenced Entities (A Customer class with a hurge list of Orders, with all order data, placed inside is wrong DDD aggregate modeling) but somewhere in your app you have to show full order list.
4. Your Views and Aggregates can be retrieved from different data sources (usually for query performance and/or eventural consistency). ie NoSql readmodels, a non normalized relational database or precomputed views (instead of tables representing your Entities) in your domain relational database.

So you have a impedance mischatch betwen UI and Aggregates/Entities. The best way to resolve this is create, explicitly, a way to deal from persistence to view. Finders comes into play.

• Repoisitories

When a user issue a command that implies a change in your domain you have to retrieve an aggegate and use the aggregate root as entry point of the action. This ensures consistency and invariants (rules) of your domain. Aggregate modeling has a lot of nuances (take a look here ) that makes bad idea to try using aggregates and entities for your views. So you need a way to read and build in memory aggregates from data sources. This is the job of repositories. Sometimes repositories gives you extra features that you do not need when retrieve data for views like entity change tracking, creation of unique identifications to persist, etc. You do not need anything of this when dealing with views. Repositories comes to play.