Chapter 11: Context Matters

Overview

THIS CHAPTER IS ABOUT message-based processing in local applications. Here you learn how you can intercept calls to objects to route them through IMessageSinks. This routing allows you to create and maintain parts of your application's business logic at the metadata level by using attributes. You also discover why it might be a good idea to do so.

Caution 

Everything in this chapter is 100 percent undocumented. Reliance on these techniques is not supported by either Microsoft, the publisher, or the author of this book. Use at your own risk! If your computer won't work afterwards, your toaster blows up, or your car doesn't start, I assume no liability whatsoever.You're now about to enter the uncharted territories of .NET and you do so on your own risk. I can only provide some guidance.

Well, it's great that you're still with me after this introductory warning. So let's start with a look at some common business applications. You will quite likely have some object model that holds local data before it's committed to the database. Those classes will contain parts of your business logic. For example, assume that your application provides an instant way for employees of your company to donate various amounts of their paychecks to charity organizations. In that case you might have a data object that looks like the one shown in Listing 11-1, which allows a user to set an organization's name and the donation of a specified amount to it.

Listing 11-1: The First Version of the Organization Object

 using System; namespace ContextBound {    public class Organization    {       String _name;       double _totalDonation;       public String Name       {          set          {             _name = value;          }          get          {             return _name;          }       }       public void Donate(double amount)       {          _totalDonation = _totalDonation + amount;       }    } } 

You might also have some database restriction or business logic that limits an organization's name to 30 characters and allows a maximum donation of $100.00. Therefore you need to extend Donate() and the setter of Name to check for this logic:

 public String Name {    set    {       if (value != null && value.Length > 30)       {          throw new Exception(“This field must not be longer than 30 characters”);       }       _name = value;    }    get    {       return _name;    } } public void Donate(double amount) {    if (amount > 100)    {       throw new Exception(“This parameter must not be greater than 100.”);    }    _totalDonation = _totalDonation + amount; } 

You're checking the business logic and your application works as expected. So far, so good. The problems only commence as soon as more developers start using your objects as the base for their applications because they don't know about those restrictions by reading the interface definition alone. As in most real-world applications, the business logic is in this case hidden inside the implementation and is not part of the metadata level. There is no way for another developer to tell that the maximum amount for a valid donation is $100.00 without looking at your source code.

If you're a well-informed developer, you already know that you can at least document those parameters using inline XML comments to automatically generate online documentation for your classes—but you still have to document and implement the logic in two separate places. If you've never, ever changed any implementation detail without updating the inline documentation, you don't need to read further—you already solved the problem.