When to determine if you have too many layers or too much abstraction
I have a simple Struts application that has the following layers:
Action -> SessionFacade -> BO -> DAO
SessionFacade, BO, and DAO all have a interfaces for each object in that layer and a factory to abstract the creation between the layers.
While the implementations for this simple app will never change, the abstraction separates Actions from knowing its calling EJBs (because it gets the SessionFacade through a Factory) and the SessionFacade gets a BO through the Factory, and the BO gets a DAO through a Factory. This separation plus each class having an interface, allows for testing a specific layer through the use of Proxies and things as such.
Is this overkill? And when do you determine that you are creating too many layers or levels of abstraction? I know we have had discussions in our group about dumping interfaces because the implementations never change enough for them to be hidden behind interfaces...and that way the codebase would be smaller and simpler. Is it right to architect a system just to make the codebase simpler?
Thanks,
jay
[1110 byte] By [
jaybyteza] at [2007-10-3 2:18:48]
Its too much when you have no compelling reason to continue to maintain it. Typically this comes in the form of annoyance at maintaining some code that never realizes its purported benefit.Can I assume the interfaces for the DAO belong to the BO layer? Or to some other layer?
That's right.
1)The Action has code to retrieve the SessionFacade interface through the Factory.
2)The SessionFacade has code to retrieve the BO interface through the Factory.
3) The BO has code to retrieve the DAO through the Factory.
The SessionFacade is used for just security and transactions.
The BO holds the business logic.
The DAO is a wrapper around iBatis.
I am trying to make it so that each layer can be tested individually or the application can grow more easily (which is not always necessary).
jay
> I have a simple Struts application that has the
> following layers:
>
> Action -> SessionFacade -> BO -> DAO
Action is strictly Web tier, all Struts
SessionFacade abstracts the service from how it's accomplished.
Business objects are the heart of your model for the system.
DAO keeps persistence code away from all the rest.
So what's wrong with this?
> SessionFacade, BO, and DAO all have a interfaces for
> each object in that layer and a factory to abstract
> the creation between the layers.
Don't necessarily need interfaces for BOs, but the other two should be interfaces.
Don't need factories if you use a DI framework like Spring.
> While the implementations for this simple app will
> never change, the abstraction separates Actions from
> knowing its calling EJBs (because it gets the
> SessionFacade through a Factory) and the
> SessionFacade gets a BO through the Factory, and the
> BO gets a DAO through a Factory. This separation
> plus each class having an interface, allows for
> testing a specific layer through the use of Proxies
> and things as such.
>
> Is this overkill?
Compared to what? Putting all that stuff into a huge Action class that can never be used outside of Struts? I don't think so.
> And when do you determine that you
> are creating too many layers or levels of
> abstraction? I know we have had discussions in our
> group about dumping interfaces because the
> implementations never change enough for them to be
> hidden behind interfaces...
Two interfaces are killing you? Please.
What do you accomplish by dumping them? Doesn't provide any simplification, IMO.
> and that way the codebase
> would be smaller and simpler.
.java file count goes down, but I'd argue that it's no simpler. The fact that it's smaller doesn't make any difference.
> Is it right to
> architect a system just to make the codebase simpler?
Sure, but this is hardly any example of bloat. (I might change my mind if I saw your code base, but I can't judge based on what you've posted.)
I would only say that BOs don't usually have interfaces when I write them. Unless it's a hierarchy where I want to take advantage of polymorphism.But if I have an Address class that encapsulates the usual suspects, I don't have an interface for it.
EJBs might be bloated and overkill. But that wouldn't change the rest. What you've posted just looks like typical layering to me.
%
>
> Is this overkill? And when do you determine that you
> are creating too many layers or levels of
> abstraction? I know we have had discussions in our
> group about dumping interfaces because the
> implementations never change enough for them to be
> hidden behind interfaces...and that way the codebase
> would be smaller and simpler. Is it right to
> architect a system just to make the codebase
> simpler?
By getting rid of interfaces you think that would make the codebase simpler?
Interfaces are trivial. Even if they are not needed they are not going to be the sole source of a design problem.
No, if he got rid of the interfaces he would not be able to test each layer individually.
> That's right.
>
> 1)The Action has code to retrieve the SessionFacade
> interface through the Factory.
> 2)The SessionFacade has code to retrieve the BO
> interface through the Factory.
> 3) The BO has code to retrieve the DAO through the
> Factory.
>
I think above you mean to say the X retrieve the Y implementation through the factory.
Using a factory is not directly related to using DI or not. A factory does not remove a dependency it only shifts its location. You still have to get the factory somehow.
> No, if he got rid of the interfaces he would not be
> able to test each layer individually.
You can't test implementations individually?
He should not be getting rid of the interfaces, but this is not the best justification for keeping them.
> I think above you mean to say the X retrieve the Y
> implementation through the factory.
>
> Using a factory is not directly related to using DI
> or not. A factory does not remove a dependency it
> only shifts its location. You still have to get the
> factory somehow.
The DI ends up acting as the factories, so you don't have to write them.
%
> By getting rid of interfaces you think that would
> make the codebase simpler?
>
> Interfaces are trivial. Even if they are not needed
> they are not going to be the sole source of a design
> problem.
If you have a tool like IntelliJ, you can generate the interface for an existing implementation, or visa versa, with a single command. (Have to fill in the meat of the implementation, of course.)
Trivial, indeed. Don't lose those interfaces.
%
Hi,
> Is this overkill? And when do you determine that you
> are creating too many layers or levels of
> abstraction? Is it right to
> architect a system just to make the codebase
> simpler?
I think that you have already answered your question in your original text. You
wrote: "...This separation plus each class having an interface, allows for
testing a specific layer through the use of Proxies and things as such...." So
the answer is: No it isn't over kill because you have system requirement
(testing) which MUST be satisfy during a system development. So sw
architecture MUST reflect this requirement. And so you need that layer of
abstraction. If you don't have that requirement you don't need the abstract
layer. Yes, of course we can discussed whether your solution is the best.
Honestly I don't know because I don't know all your requirements but I can
say from my experience that proposed testing should be a good way.
IMHO SW architecture should satisfy all requirements (functional and also
non-functional) but don't need to have things beyond of them. I think that
mapping between sw/system architecture and all significant requirements
should be done. If some requirement is not satisfied -> architecture is not
done. If an architecture has attributes that are not required it means that it is
not architecture but shiny toy.
PetrGa at 2007-7-14 19:17:42 >
