Session Facade / Business Facade

[spring04]

Hi All,

In our Spring/Hibernate based project, we are in the design stage. In this, i ran into a question of where should the biz logic be written. Should it be in Session Facade (which is implemented as stateless (local) session bean, in our case) or in the Business facade (which is also a service layer?).

Per my understanding, Session Facade will provide one point interface to the client. Session Facade will call the Business Facade. For example, we've various POJOs (e.g Application) and for each of the POJOs or related POJOs, we'll have the service layer API (e.g ApplicationManager). If the ApplicationManager has a method called saveApplication, this method will carry out biz rules a, b, c before saving the application POJO using the corresponding DAO interface. SessionFacade will call appropriate service layer API.

Is that the recommended approach???

Also, in our case, for certain CRUD operations, we are planning to use Hibernate and for others, especially queries, we are planning to use just Spring's JdbcTemplate and even stored procedures, if required for performance reasons.


My question is, within the same transaction can mix and match the use of Spring based JdbcTemplate for querying, HibernateTemplate for saving and stored procedure for some other logic (only if required). In this case, will spring manage the DB transaction/connection for all of them. What happens if we persist (save) more than one objects within the same transaction and one of them fails. In this case, will spring rollback all of them?

Is it logical to mix and match Spring based JDBC operations vs Hibernate within the same transaction?

Could someone please share your thoughts on this?


Thanks for any input in advance!

[Rod Johnson]

In our Spring/Hibernate based project, we are in the design stage. In this, i ran into a question of where should the biz logic be written. Should it be in Session Facade (which is implemented as stateless (local) session bean, in our case) or in the Business facade (which is also a service layer?).

Per my understanding, Session Facade will provide one point interface to the client. Session Facade will call the Business Facade. ...

In this case I would view your SLSB as no more than an entry point. I would put the business logic into the Spring-managed POJO, which will allow easy using testing and other advantages.

In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all.

My question is, within the same transaction can mix and match the use of Spring based JdbcTemplate for querying, HibernateTemplate for saving and stored procedure for some other logic (only if required). In this case, will spring manage the DB transaction/connection for all of them.

Yes.

What happens if we persist (save) more than one objects within the same transaction and one of them fails. In this case, will spring rollback all of them?

If you get an exception, Spring will rollback the transaction. The transaction being a transaction, it will be atomic, so all operations will roll back.

Is it logical to mix and match Spring based JDBC operations vs Hibernate within the same transaction?

Often, yes, but you need to be careful if JDBC is updating tables that Hibernate maps. (Cache coherency.)

[spring04]

Thanks very much for your detailed reponse Rod.

In our Spring/Hibernate based project, we are in the design stage. In this, i ran into a question of where should the biz logic be written. Should it be in Session Facade (which is implemented as stateless (local) session bean, in our case) or in the Business facade (which is also a service layer?).

Per my understanding, Session Facade will provide one point interface to the client. Session Facade will call the Business Facade. ...

In this case I would view your SLSB as no more than an entry point. I would put the business logic into the Spring-managed POJO, which will allow easy using testing and other advantages.

In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all.

In our case, we've non-web Mac native cocoa client which sends the request in XML format. We've a server which receives this request and pass it on to the SLSB. Hence this SLSB is local. We are introducing this SLSB so that in the future if we want to write web client for any reason, we can use the same entry point. Please let me know if that's not the recommended approach.


If i put business logic into spring-managed POJO, is it not defeating the purpose of the POJO? POJO in my understanding should be just plain in JavaBean style so that it can be re-used as required. Wouldn't it polute the POJO model? Am i missing something?

[Rod Johnson]

We've a server which receives this request and pass it on to the SLSB. Hence this SLSB is local. We are introducing this SLSB so that in the future if we want to write web client for any reason, we can use the same entry point. Please let me know if that's not the recommended approach.

I would not advise introducing EJB at this point just because requirements might change in future. Also, as you're using Spring, you should consider Spring's own POJO-based remoting. With Spring and Dependency Injection once you define the business interface, you can switch to an EJB implementation very easily without impacting callers.

If i put business logic into spring-managed POJO, is it not defeating the purpose of the POJO? POJO in my understanding should be just plain in JavaBean style so that it can be re-used as required. Wouldn't it polute the POJO model? Am i missing something?

POJOs, like all objects, are the correct place for business logic. A pure JavaBean is a struct, not a real object. I would view structs as being true pollution of your object model

Rgds
Rod

[manifoldronin]

This whole conversation reminds me of the right-on statement of Eric Evans's, which is also highlighted in Martin Fowler's Anemic Domain Model article:

Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate object, gradually slipping toward procedural programming.

[Rod Johnson]

I agree 100% with Eric. As it happens, I was sitting with Eric (we were cohosting a BOF at JavaZone in Oslo) when I wrote my last post in this thread.

Eric and I have been discussing working together on an example of realising DDD with Spring. Hopefully we'll be able to get something happening before the end of the year.

[manifoldronin]

Eric and I have been discussing working together on an example of realising DDD with Spring. Hopefully we'll be able to get something happening before the end of the year.

Cool! Call it "Architecture War Episode VI: Return of POJOs"