A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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?
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?
Thursday, June 07, 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.
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.
Friday, June 08, 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.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz