Object design questions
- From: "Mike" <michaelloll@xxxxxxxxxxx>
- Date: 5 Jun 2005 13:42:00 -0700
Hello all, I'm hoping you may be able to point me in the right
direction on this. It pertains to a common design we use at my
employer for software applications.
Typically, we will divide our application into a few distinct layers:
UI
Application
Business
Data
This layout was obtained from some design docs in our Rational Unified
Process documentation.
The UI layer is typically a set of web pages which interact with the
Application layer via some MVC framework. We use .NET, and we are
using the Maverick.NET MVC framework, which is a port of the Java
framework. I don't think the technology is too important here, but I
thought I'd throw that out there.
The application layer typically exposes one controller object, which in
turn will talk to one or more internal controllers which handle certain
sections of the system -- authentication, accounts, orders, etc.
The application layer interacts with the business layer to get data and
manipulate them.
In turn the business later talks to the data layer to persist and
retrieve data from a dat astore.
I think this is fairly typical and not hard for anyone reading this to
grasp.
My issue comes when we design our classes. Typically, most of our
business logic is grouped in the controllers, and the methods exposes
by the controllers typically mimic some process the end user will be
requesting. I don't necessarily have a problem with this, but it ends
up making our business objects simply wrappers over our data objects
(which closely follow our data schema). Typically a business object
will wrap a data object and expose its properties via setters/getters.
A typical request for saving an order looks like this:
1: User submits updated order information.
2: MVC determines which http handler class to use.
3: Http handler class (the controller in MVC) calls our application
controller.
4: The application controller in turn calls our order controller,
passing in the relevant parameters.
5: Order controller calls the business layer to get a specific order
object.
6: Business OrderFinder object calls the OrderDataFinder object to get
a specific order.
7: OrderDataFinder returns OrderData object to business OrderFinder
object, which wraps OrderData inside an Order object.
8: The OrderController updates the various properties of the Order
business object.
9: The OrderController asks the business layer to persist the changes.
10: Business layer asks the data layer to persist the changes.
11: User is redirected to a new page.
I wish I could draw a sequence diagram for you, but here is my best
attempt if the above is not clear (I've prefaced each with letters to
indicate the layer they reside in):
[UI]->[MVC]->[A:AppController]->[A:OrderController]->[B:OrderFinder]->[D:OrderFinder]
That describes steps 1 through 7 really.
My concerns:
1: My business objects are simply wrappers of data objects. This
smells bad.
2: The business and data layer versions of my finders are essentially
the same, except what they return. This smells bad.
Any advice? Any good books on this subject? Anything else that smells
bad that I am not seeing?
Any help is appreciated.
Thanks.
--
Mike
.
- Follow-Ups:
- Re: Object design questions
- From: frebe
- Re: Object design questions
- From: Robert C . Martin
- Re: Object design questions
- Prev by Date: Re: Full life cycle development
- Next by Date: Re: UML: Associations between classes and packages
- Previous by thread: UML Question (Object <-> ObjectFinder?)
- Next by thread: Re: Object design questions
- Index(es):
Relevant Pages
|
