Questions regarding my layered design.

Question

User-1833980242 posted

I have a web app that is in it's own project.  I have a class library project, in the same solution, that has the BO, BLL and DAL code in it for the web app.   Each of these layers; BO, BLL and DAL are in their own folders.  The business objects are in their own individual class files with public properties that encapsulate the private fields.  It seems to be very standard n-tier or n-layer stuff.

Now that I got this working, I want to implement exception handling.

My questions are about each of these layers.  I'm going to use validation controls to prevent the user from entering garbage input.  But I also think I should enforce the business rules in the BLL as a second line of defense.  Since this is what business logic refers to.

In the BLL I plan on using code to enforce business rules and throw an exception if (some how) bad user input gets past the validation controls in the UI.  Then in the DAL I want to handle the exceptions that are returned by sql server.  

 My questions are as follows.  Should I also implement guard code in the properties for my objects(in addition to the logic in the BLL)?  Would I be doing this correctly to handle business rule violations with exceptions in the BLL and let the DAL handle exceptions for Sql Server?

Answer 1

User2130758966 posted

In theory if you are using asp.net validation controls you will perform client side validation for quick feedback and then the system automatically performs a server side validation after postback to ensure the javascript wasn't compromised. As long as you check the Page.IsValid before passing any data down to your lower layers.

In theory if you have written good validation code in your ui then you would end up using identical error checking in a lower layer.

Its a well discussed fact that asp.net webforms puts the validation logic in a bad location (the ui layer) but hopefully the improved dynamic data integration in .net 4 will make it easier for us to keep our validation rules further down inside the codebase.

It seems a bit pointless to duplicate your validation layer further down as it would just mean more maintenance to keep them both in sync. However if there is any possibility that you will expose these layers via other ui layers like desktop app, web service, mvc ui, etc then it would be worthwhile to implement these checks.

As for specific exception handling advice I would say you should try to handle exceptions as close to where they occur as possible so going by this line of thought your suggestion to handle business rule violations in BLL and sql server exceptions in DAL seems correct.

Answer 2

User-1833980242 posted

Thanks for your informative response.  It seemed like a lot of unnecessary redundancy to implement the validation on all of the layers.  It's also good to be aware of the limits of the validation on the UI and how it wouldn't be used if an additional interface or another application was used.