BackDraft

IsThere Business Logic in Your Middle Tier?

By Jonathan Goodyear

Most Webdevelopers are familiar with the concept of an n-tier application.Although "n" implies three or more tiers, three is the standard: userinterface, business logic, and data. In Classic ASP, the user interface tierconsisted of HTML tags interspersed with VBScript to build the page layout. Thedata tier was a database such as SQL Server. The business logic tier sandwichedin the middle, however, was often horribly underused.

In mostClassic ASP Web applications I've seen, the business logic tier really didn'thave any "business logic" in it. It merely consisted of stored procedure (orembedded SQL) calls wrapped inside Visual Basic pass-through components. Infact, the only reason Classic ASP developers used VB components at all wasbecause of the performance advantage of leveraging compiled code. It's quiteobvious that the term "object-oriented" was merely paid lip service during theClassic ASP era.

Butlet's jump ahead to the wonderful world of ASP.NET. In ASP.NET, every page isinherently an object, so you can't help but develop object-oriented code,right? Unfortunately, this has not been the case for many Classic ASPdevelopers making the switch to ASP.NET. They are still mired in the old way ofthinking when it comes to the business logic tier of their applications. MostASP.NET applications I see today have ever fattening user interface tiers (incode-behind logic), and the thinnest business logic tier imaginable.

Thistime around, the performance-advantage argument no longer applies. All the codein ASP.NET is compiled, so that benefit went right out the window. The onlyslight advantage that remains is that you're encapsulating your storedprocedure calls - hardly the vision that our object-oriented forefathers had inmind.

Sowhat's missing? The logic of course. To effectively leverage object-orientedconcepts in your development, you need to change the way you think about yourbusiness logic tier. Instead of thinking of it as nothing more than a means toextract data from your database, think of and build your business logiccomponents as an SDK (Software Development Kit), not unlike the .NET Frameworkitself. Inheritance, polymorphism, and all the other object-oriented goodiesthat .NET provides for you make this process a snap.

I wrotean article on organizing your .NET namespace structure (http://www.fawcette.com/vsm/2003_04/online/goodyear/default_pf.aspx),so I won't go into that too much here. Suffice it to say that in your company's.NET object hierarchy, your company name becomes the top-level namespace(similar to the System namespace in the .NET Framework) and applicationand functional sub-systems make up the rest of the namespace hierarchy, stayingas close as possible to the standard namespaces implemented in the .NETFramework.

Even themost organized .NET namespace hierarchy doesn't solve the problem, however, if yourbusiness logic components don't have the right logic in them. There are a fewfundamental things that all your business logic components should contain.First, they should be self-validating. When you build your business logiccomponents into an SDK, you are effectively disconnecting it from your Webapplication, and any input validation that it performs. Therefore, yourbusiness logic components are the last line of defense to make sure that onlyvalid values make it into your database. Even if you have field valueconstraints implemented in your database, you'll still want to validate yourinput data so you can throw more informative custom exceptions to the consumersof the component, whatever that consumer may be.

Speakingof database connectivity, each of your business logic components that talks toa database should inherit from a base class that implements a property for adatabase connection string. Because your components can now be used by multipleconsumers, you can't have any connection string retrieval logic baked intothem. It is much better to have the consumer provide that information at runtime.

I'm afirm believer that the user interface tier of any application (includingASP.NET Web applications) should be ADO.NET-free. ADO.NET is a great technologyfor retrieving and manipulating data, but it isn't very well suited torepresenting the logical entities in your application. Typed DataSetsare about as close as you can come, and those are an absolute nightmare tomanage (Whidbey will go a long way toward fixing this).

Instead,your business logic components should distill your ADO.NET objects into objectsthat represent the entities in your system. For instance, if you're retrievinga list of customers from your database, don't return a DataSet withcustomer information in it. Instead, create a typed collection of Customerobjects and pass that back. While you're building that typed collection, you'llalso have the opportunity to perform any other necessary logic that wasn'tperformed by the stored procedure.

As longas your typed collection implements the IEnumerable interface, you'llstill be able to bind it to all the server controls that you know and love.You'll also be able to take advantage of all the custom properties, methods, andsub-objects that you've implemented in your objects. IntelliSense alone will beenough to sell you on that feature.

Thebottom line is that the code-behind class for each of your ASP.NET pages shouldonly contain the glue that binds your company's business logic SDK with theelements of the page, and the elements of the page to each other via eventwire-ups (where applicable). Put all the real logic that makes up your Webapplication into a framework of business logic components that can be re-usedby any number of different consumers: Windows Forms applications, Web services,mobile devices, etc. Moving to ASP.NET requires more than just changing thetechnology or platform you're using. It means finally changing your mindsetabout the way an application is built, and where its constituent pieces go.

Hopefully,the ideas I've presented here will get you started in the right direction.You'll definitely find that your applications come into focus much more quicklyand easily using this approach.

Jonathan Goodyear is presidentof ASPSoft (http://www.aspsoft.com), anInternet consulting firm based in Orlando, FL. He's a Microsoft CertifiedSolution Developer (MCSD) and author of Debugging ASP.NET (New Riders). Jonathanalso is a contributing editor for asp.netPRO. E-mail him at mailto:jon@aspsoft.comor through his angryCoder eZine at http://www.angryCoder.com.