[MUSIC]

Now that we have Hibernate up and running in our application,

we could certainly continue down this path and finish the app so

that all functionality is present from the perspective of the user.

We could autowire a SessionFactory into the GIF controller as well, and for both

controllers implement all of the Hibernate operations in the controller classes.

But there would still be some glaring problems with that.

What if we wanted to use unit test to test just the controller or

just the Hibernate functionality?

This would be impossible since those two components are now woven together in our

source code, which is also known as being tightly coupled.

Or what if we wanted to provide the same Hibernate functionality to a Giflib API

that we're writing which helps power a native Android or iOS app?

Right now, all that functionality is woven together with our web app functionality,

which is written specifically to serve HTML.

Again, too tightly coupled.

Another practical concern is the idea of another developer joining our team

to fine-tune Hibernate so

that its queries are efficient and our application is speedy.

Unfortunately that developer is going to have to sift through

all of our web-specific code in the controllers.

The considerations we're making now have to do with software design,

which we'll refer to here as the organization of our application in

the placement of code into classes, the placement of classes into packages, and

the relationships among all our classes.

While developing applications, we want to maximize the following,

maintainability, extensibility, reusability, and testability.

Out of these needs arise the principles of first, the separation of concerns,

where each layer, which could be a package or jar file, performs specific duties.

For example, the controller layer intercepts and routes URI requests.

And a data access layer interacts with our database via Hibernate.

Next is the single responsibility principle,

where each class addresses a single concern.

For example, the CategoryController intercepts URI requests to

resources related to categories, makes simple calls to fetch or alter data,

then serves the appropriate HTML template or routes the request to another URI.

Currently we're violating this in our application,

where the CategoryController handles URI requests and interacts with Hibernate.

Think of the single responsibility principle like the separation of concerns

within application layers.

Finally we have the principle of loose coupling,

which means that each object can act with little knowledge of other objects.

For example, we use interfaces to generalize functionality and

define fields with interfaces.

The implementation is provided or injected elsewhere.

We saw this in our definition of a data source.

As far as Spring is concerned, we have only leverage the java.sql.DataSource

interface even though the actual object returned by that method

will be a BasicDataSource provided by the Apache DBCP library.

In this case, Spring acts with no knowledge of its implementation, but

only expects the implementation to have implemented java.sql.DataSource.

If you haven't seen these principles yet,

expect to see them come up often as you gain more development experience.

These are principles that every software team is interested in implementing.

So building a strong foundation of knowledge in them and

having the practice to back that up with is going to be a great asset for you.

Next, we'll look at how these principles will apply to our Spring web apps.