The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Single point of entry between aspx pages ans th BO layer

I'm creating a simple CRUD web app using C#. I'd like to simplify the connection between the presentation layer i.e., the ASPX pages and the BO layer. I want to create an ObjectRouter object that takes any kind of DTO object and either saves it, deletes it, or creates it. The Router would determine the type of object and pass it on to the appropriate Business Object. This seems like a good way to simplify the code on the Presentation Layer. Anyone see any downsides?
Curtis Erhart Send private email
Thursday, June 07, 2007
The downside I see is adding an extra layer in what sounds like a simple application.  IOW, why do you need this additional complexity?  The presentation layer either does customer.Save or router.Save(customer). How is the second one simpler?
Mike Stockdale Send private email
Thursday, June 07, 2007
All of the presentation code would call One object is used instead of many. Encapsulation and all that. Maybe the gains are insignificant.
Curtis Erhart Send private email
Friday, June 08, 2007
Also, if I have two developers working on the same project. One is writing the presentation layer and the other is working on the BO, we can quickly whip up an interface the presentation developer can use and then implement it later. The two developers can work simultaneously with minimal communication.
Curtis Erhart Send private email
Friday, June 08, 2007
Why not create an "API" class?  Instead of routing based upon a text string, just have a thin class with individual methods exposed.  Instead of "router.command("SaveCustomer", ...) just have router.SaveCustomer(...).

Hint from Martin Fowler's "Rafactoring" avoid switch parameters.
Wayne M.
Friday, June 08, 2007
I'm thinking of just calling dto) for all objects, and let the router decide which function to call depending on the type of the object (entity class) passed.
Curtis Erhart Send private email
Monday, June 11, 2007
I do this all the time. One point of entry.
Friday, June 22, 2007
>Anyone see any downsides?

-Debugging will be a bit more annoying with another method and probably a huge switch to walk through.

-More opportunity for merge conflicts in the source control system.

-Adding new saveable objects will have another step added.

-Difficult to determine what pages will be affected by a data design change.

Those are all small downsides, but what are the upsides?  It doesn't really simplify the page code other than not forcing the UI coder to know what object to save, although that coder will have to have created the correct object in the first place.  You can get the exact same benefit by implementing an interface on all of your business objects with a Save method.  Now you just call "Save" and it saves, no questions asked.

Why use a DTO at all?  Just use the BO.  The only reason I can think of for seperating the DTO from the BO is if you expect to use the data in a location where many of the business methods could not be called.  DTOs are often used in methods for Web Services for this reason.
JSmith Send private email
Saturday, June 30, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz