Professional UML with Visual Studio. NET. Unmasking Visio for Enterprise Architects

We mentioned a few benefits of using business objects in this chapter's introduction, but we're going to dive a bit deeper to provide a rationale for using business objects in your application. Building applications with components initially adds a degree of difficulty to your software development, so it's good to establish compelling reasons for doing so. To do this, we'll first look at the alternative - building monolithic applications.

Flexibility - Write Once, Reuse Everywhere

When building a Windows Forms desktop application, many developers have it in the back of their mind they also need to provide access to the application via the Internet. However, if you build a monolithic application, where the majority of your application logic is tucked away inside the methods and event handlers of a Windows Form, when that user interface goes away (replaced by a Web browser) all your application logic goes with it. How can you access application logic that is stuck in the methods of a Windows Form from an ASP.NET application? The answer is you can't.

In contrast, as shown in the following image, if you place application logic in business objects, these objects can be accessed from a Windows Forms application, a Web Forms application, or a Web Service.

Data-Access Flexibility - Write Once, Change Once

Will your application access SQL Server data, Oracle data, or something completely different? The answer to this question might change mid-development or maybe even after your application is deployed. Most of the .NET sample code published in books and magazines places data-access code in the user interface. However, the .NET Framework uses a different set of classes (.NET Data Providers) to access different kinds of data, so if your application data changes, and your data-access code is scattered throughout the user interface, you've got quite a code change on your hands.

In contrast, if all data access takes place through your business objects, you only have one place you need to change your data access code - in the business object. In reality, good business object design dictates that your business objects should have data-access classes that you can switch in and out depending on the type of data you need to access.

Normalizing Application Logic - Write Once, Period!

Good database designers know how to normalize application data. The term "normalize" refers to eliminating redundancies in data. But have you ever thought about normalizing your application logic? If you ever get an opportunity to look at code written by teams of developers, you'll often find the same application logic repeated several times over in a single application. When you place application logic in the user interface, there are no checks and balances preventing you from creating the same logic repeatedly.

Again, business objects come to the rescue. When you place your application logic in business objects, it's far less likely you will create two methods that do exactly the same thing. When all forms in the application use the same business objects, developers have a common repository for application logic.

Where's the Code? - Write It and Find It

Have you ever played "Where's the code?" If you've built monolithic applications, I'm sure you have. When application logic is scattered throughout the user interface, it can be very difficult to debug and maintain. In a monolithic application, you can spend countless hours hunting through hierarchies of user interface controls to find the code you're searching for.

In contrast, if you place your code in business objects, you lift it out of the 'weeds' and logically segregate it into business components making it easier to debug and maintain. If you have a bug in the invoicing portion of your application, you can be quite sure the problem code is in the Invoice business object. If you need to modify the way you handle inventory, it's a safe bet the code you're looking for is in the Inventory business object - and if you've named your business object methods well, it makes it even easier to determine where the code resides.

Designing Complex Software

Although last in the list, this benefit is not least in importance. When you elevate your programming by using business objects, it can help you better conceive and design complex software systems. In a monolithic application, something known as a semantic gap exists. This gap is the breach between your software system and the real world. Monolithic systems do not have objects that correspond to real-world entities, thereby creating this gap.

In a component-based application, business objects bridge this gap. Because you can create business objects that represent real-world entities, it is easier to solve real-world problems. I have a number of clients who struggled with thorny conceptual problems for weeks or months, without coming up with a solution. The simple act of creating business objects and manipulating these on class and sequence diagrams helped solve these thorny issues each time.