How do the Application and Database Interface Layers interact at their boundary?

Question

I was watching one of Uncle Bob's videos and he brought up the Database Interface Layer. He had this diagram showing it:

These arrows show that the DB Interface Layer is aware of and calls the Application and Database layer, but not vice versa.

The DB Interface Layer has "data records" in it. These are "classes" that have the name of the table and the fields of the columns. These are what I usually call DTOs. But these data records have all public fields and no/few methods.

The DB Interface layer is responsible for grabbing the data from the database, populating the "data records" and implementing an interface in the Application Layer like so:

I'm a little confused because I've never heard about this separation before. Every project I've worked on uses the DTOs in the view which is apparently wrong (at least according to Uncle Bob's video).

Also, I've never worked on a project where the DB Interface Layer calls the Application Layer. It's always the Application layer asking the DB Interface Layer for information. For example, by using a DAO.

But this is starting to make sense. Whenever I use hibernate I'm always pulling my hair out because I try to make the DTOs more OO and the library always fights me.

So, I guess what I'm trying to ask is, what does the code look like on/at the boundary between the Application and the Database Interface Layer? For example, how does the Application get the implementation of the Order Gateway Implementation? Is the Order Gateway Implementation a DAO? I don't have a clear picture of how the POS can use the Order Gateway vs how/when the Order Gateway gets populated with data.

Answer 1

I think you interpreted the pictures in a wrong way! The arrows do not represent call direction in my opinion.

When you look at the 2nd picture, it's obvious that Order Gateway Implementation implements the Order Gateway interface and objects of type Order Gateway are used from the client type POS. So the actual direction of call is top down as you would expect it.

This is just an application of the Strategy Pattern in order to separate your database structure which lies inside the DB I/F layer from its interface the application layer uses. If you hadn't the DB I/F layer your application layer would probably directly access specific DB structures, which would definitely not be the right way to go in being flexible with the DB technology.

Edit:

Well, let's bring the notion of DTOs to our mind: Those are objects containing certain amounts of data (no behaviour) aggregated for a specific purpose, usually to push them over the net in distributed systems. Although they're used in this context as Order Table and Line Item Table, there is no contradiction to using DTOs for views since views are also usually only bound to data.

The DAO's purpose is in the first place to encapsulate as much as possible from data source technologies. Since the DAO isn't only a single object, but a pattern including the interface and its implementation, you can map the DAO pattern directly to Order Gateway interface and Order Gateway Implementation resulting in no dependencies from application layer to specific data structures.

Answer 2

I'd like to add that while the arrows do not represent call direction, what they do represent is dependency.

By introducing the "Order Gateway" interface in the Application Layer, and implementing that interface in the DB Layer, instead of the Application Layer taking a dependency on the DB layer, it will be the opposite; we have inverted the dependency direction.

This is a decoupling strategy called Dependency Inversion which would let you swap out the DB layer without changing the Application Layer.

Answer 3

I think your confusion comes from the term "Interface".

There is a DatabaseInterface-Interface and a DatabaseInterface-Implementation.

The Applicaton layer knows and uses the DatabaseInterface-Interface to get data from the database into dto-s or daimain-objects.

The DatabaseInterface-Implementation implements the DatabaseInterface-Interface and knows/uses dto-s.

Many developpers call this the Repository-Pattern

If the arrows in your picture means "uses or calls" then the arrow from "Interface" to "order" in the 2nd image has the wrong direction.