Geek Answers Handbook

Deep and object model

What would you recommend - a hierarchy of deep objects (where each object contains a link to its child objects) or flat objects (where you provide services for retrieving child objects)?

Suppose you are creating a database management application. You will have objects such as:

  • Server
  • Database
  • Columns
  • representation

Which option would you recommend:

  • Each server object contains a list of database objects. Each database Object contains a list of columns and a list of views, etc.
  • Each object is a "dumb" object that contains only its own properties and you provide a set of services for retrieving the hierarchy, for example GetServerDatabases (Server), GetDatabaseColumns (database).
+4
source share
6 answers

If you follow the principles of designing OO, then both of them are true. The second option is known as a coordinating object and helps prevent tampering and disruption to the state of your API / Core (no matter what name you want).

The first option is how it is stored internally, and you can optionally allow access to the database server property if you want to allow it.

My own preference would be to restrict any setters to 4 objects and force it through the coordination / facade object ( facade template ). Let the Server offer its databases as a property, etc. Down the chain.

As indicated, the Server.Databases property can be heavy. In this case, it can be accessed through the coordination object (facade).

So:

GetServers() GetDatabases(Server) GetColumns(Database)

etc.

+3
source

The second approach, I believe, corresponds to the FlyWeight template: objects do not bring them directly with children, they just know how to get to them. When working with databases, you don’t need the entire hierarchy present all the time, so in this context I would prefer a dumb approach.

However, FlyWeight may be enriched with some caching to avoid multiple searches for the same data.

+2
source

If you work with OR-Mapping as Hibernate, I would use a specific hierarchy of objects.

+2
source

You could get around both. A deep model for teams and a flat model for queries. This is called Command Query Separation (CQS) and I recommend learning more about this before applying.

+2
source

I prefer the first approach. Although you can sometimes overestimate and create classes that are too granular, in general I find that a tree, like a structure, with every object that has intelligence, is much better and object oriented than a set of "dumb" objects with a set of helper methods.

0
source

Your database schema should be what suits your needs. If you need referential integrity and want to rely on some cascading database functions and not face big performance bottlenecks, your schema should reflect this. When using an RDBMS, you want to flatten your tables when you have good reasons, otherwise you will have many duplicates or empty fields that consume resources and can complicate your queries, since they take into account all special cases - it’s much easier to use operations based on the set for which the DBMS is intended. If you take the approach of matching a table with every "entity" in your domain, you should be fine.

For more complex entity models +1 on CQS. In this case, you maintain a deep model for your teams and a separate, smooth version for your queries. If you do not want to follow CQS, you can smooth out your deep model in the DTO in mind. Otherwise, you can create a separate set of tables or views in your database from which you can query. The second option seems to be more consistent with CQS, and you will likely need an easier time with some more complex queries that may arise.

0
source

More articles:


All Articles