One of the primary success factors for implementing a robust framework is providing enough information at runtime so that the system can be effectively monitored . Despite how good a programmer you think you are, there will always be bugs . Hopefully, by the time your application goes to production, most of these can be discovered . However, no matter how diligent you may be, problems still arise. Eventually, you will be faced with solving the issue as quickly and as painlessly as possible. The better your framework is built to handle both preproduction and postproduction problems, the faster they will be solved .
Information is key to solving any problem. The more accurate, abundant, and accessible the errata, the better. This is especially true in postproduction, when you may not have the liberty of being seated at the desktop of your users trying to solve their issues. I hope the topics in this chapter will provide you with some "best practices" that you can employ in any application, typically at the middle tier. I provide a melee of ideas, dos, and don'ts here to give you a few tips on which can be incorporated at any level. Unlike design patterns, these are not fixed to any one design but are more specific to the .NET framework. For those repeatable implementation steps, I've included a few implementation patterns that will add some benefit to any new or existing middle tier .
Like the remaining the chapters in this book, this chapter serves as a cookbook of ideas and does not have to be read in any particular order. The following topics will be covered in this chapter: