“Are we really going to use these theories/principles at work?”

While teaching in Letran, or even while studying there a few years back, one question almost always pops up when a professor wraps up a difficult topic: “How do we apply this in the real world?” I have asked this question myself a few times, and now that I'm working in the industry again, I have this rare chance of showing you exactly how the theories are actually used in real applications. I will tag these series here as 'Theory + Reality', and the posts would be about how we can apply the theories we have learned to the software that we would create.

Reality: 
Click the Pic to Enlarge!

One of the most common task that we're going to do at the industry is to maintain and improve upon existing software. Look at the code above. This is a small piece of code from the Business Logic (BL) Layer that basically shows some collection of information about the customer. According to my previous blog post about the N-Tier Architecture, the Second Tier is basically a bridge/police between the User Interface and the Data Store, transferring while verifying the data through a set of business rules/policies. Now, let' analyze the code line-by-line.

Line 174: The Business Logic code asked for a ComboBox as a parameter. The alarms in your head should already start ringing- there's something not quite right here. A Combo Box is something the user interacts with, and the bridge/police shouldn't have anything to do with it. Theoretically, what we need is the data- what's inside the ComboBox.
Line 175: It's normally unnecessary to put an entire function in a Try-Catch block. We should only catch errors that we can fix- errors that the business logic layer, or the layers below it, actually creates. Everything else should just bubble up to whoever can resolve the error. Of course, sometimes you need to do this when debugging the code, just to be sure.
Line 176 to 184: This is simply an initialization phase for the parameters that would be used by the next process. Trivia: It's almost impossible to have a runtime error here that the Business Logic layer can resolve.
Line 185: This is the connection to the Data Store. We should hold on to the data that this returns until the User Interface needs it.
Line 186: Here, we use an external object (service as clsService) to bind another external object (the ComboBox), passing the data that we got from the Data Store, which is readily available since the scope of the Set_Get_Lookup property is Public. Obviously, this doesn't belong here. It has nothing to do with any Business Logic, and has everything to do with the User Interface. Take note that one of the features of the BL layer is that we should be able to interchange different UIs easily (this design pattern is known as loose coupling) and by binding the combobox here, we are tightly coupling this part of the code to the current interface.
Line 187: Catch ex as Exception means you would catch ALL exceptions. I will say this again: It's good programming practice to just specify which errors you catch, then let everything else bubble up. The user interface usually has this kind of Try-Catch block, to notify the user that you've done everything you could've done, but the error is still there.
Line 188: This is an impossible line of code. Business Logic layers are normally compiled in a library (a DLL) and libraries, by their very nature, are “headless”. They should never have a User Interface, so calling a MessageBox here is a logical error.

Theory + Reality
 
Click the Pic to Enlarge!

You can see in the sanitized and Diff'd code above the design patterns and theories which I applied. Specifically:

• Single Responsibility Principle. The business logic layer should have one, definite responsibility only: to act as a bridge/police for the data traveling between the UI and the Data Store. Don't let responsibilities bleed into other layers, or even other objects (also: avoid tight coupling).
• Load Once, Use Many Principle. You can find my blog post about the Lazy Initialization design pattern here.
• Better Exception Handling.

That's it! The first of the hopefully many posts in this series is complete, and I hope we've both learned a lot from these. Until the next post, sayonara :D