Question

In my n-tier architecture, I have a mapper layer to fill my responsecontext from the dataset/datatable comes from DBlayer. So DBlayer calls Mapperlayer to get the things done. But before filling responsecontext i need to do some validation. For this, shall i call businesslayer from mapperlayer? Or i should just pass what i get from DBlayer to businesslayer and ask the businesslayer to call mapperlayer.

Here, My business layer will use Business Entities to do thier own operation. Kindly help me on to sort of this design decision.

Answer 1

Either one will “work”, but I prefer not putting such things in a business object.

Having the business layer call the mapper layer creates a circular dependency between packages. The mapper layer already has to know about the business layer – that is the heart of its responsibility.

But why should the business layer know about the mapper? Mapping has nothing to do with business logic. The harm, of course, is that you can never test them independently if there’s a two-way dependency.

I’d keep it as a one-way dependency. You can test the business objects independent from the mapping objects that way.

I’d also keep the mapper inside the persistence tier, not situated between persistence and model. Have your persistence layer return business objects, not ResultSets. Let it be package private if possible. My reasoning is the same – minimum knowledge means minimal coupling.

There are different levels of validation. I’d say that data should have been validated long before it gets into your database. There should be no need to validate, except for specific business rules, when you query the database. Those rules should be part of the business transaction in the service layer, not the persistence layer.