The Business Rules Layer in an N-Tier architecture is that layer that contains the Business logic and / or Business rules of the application. Reserving a separate layer strictly for Business logic in an N-Tier architecture is a major advantage, in that any changes that need to be made to Business rules can be made here without having any effect on other applications.
Assuming that the interface among the different layers stays the same, changes that are made to the functionality / processing logic in the Business Rules Layer can be readily made without having any affect on the others. In the past, many client server applications failed to implement because the changing of the Business rules or logic was such a difficult process.
The Business Rules Layer in an N-Tier system is where all the application’s brainpower resides. It contains data manipulation, Business rules, and all the other important components that your Business needs to survive. If you happen to be creating a search engine and have the need to weight or rate every matching item according to some sort of custom criteria – let us say the number of times a keyword was found in the result of a quality rating – then the Business rules layer should be placed on this layer. The Business Logic Layer does not know anything about HTML – it does not out put HTML, either.
Nor does the Business Logic Layer care about things like SQL or ADO. The Business Logic Layer should not contain any code that enables it to access the database. Such tasks should be assigned to corresponding layers above and below it.
Business Rules Layer in Three Tier Architectures
While N-Tier architecture typically refers to three or more levels, the fact is that three level architectures are the most common. The three levels consist of the user interface, the Business rules layer, and the data. It used to be, in classic ASP, that the user interface level would consist of HTML tags alongside VBScript, which was used to construct the page layout. The data level would be a database, such as SQL server.
The Business rules layer was oftentimes underused in a really horrible fashion – with detrimental results. A lot of times the Business rules layer in Classic ASP Web applications would not even have any Business rules in it. It would merely consist of a stored procedure wrapped inside Visual Basic pass through components.
The only real reason why Classic ASP developers would even bother with VB components was due to the performance advantage of leveraging compiled code. It is rather obvious that the term “object oriented” was just an object of lip service throughout this Classic ASP period.
The Business Rules Layer in ASP.NET
Let us take a look at how the Business rules layer functions in the realm of ASP.NET. In this format, every page is inherently an object, so it would follow that logically every page is an object oriented code. This has not been the case, however, for a lot of developers who previously worked in Classic ASP who are now making the transition to ASP.NET.
Many of these developers are still thinking in the old fashioned manner when it comes to the Business rules layer of their applications. The vast majority of ASP.NET applications one sees in today’s environment utilize increasingly thicker user interface levels alongside incredibly thin Business rules levels.
In these terms, the performance advantage argument does not apply. All ASP.NET code is compiled, so the benefit of performance advantage does not exist. The only advantage that does remain is the fact that stored procedure calls are encapsulated.
The only thing that is missing now are the Business rules. IN order to effectively leverage object oriented concepts in one’s development, one must first change their way of thinking about the Business rules layer. Rather than considering it as merely a way of extracting data from the database, the Business rules components should be build as a Software Development Kit in a fashion that is similar to the .NET Framework. This process should be made easy with the object oriented tools that .NET supplies, such as polymorphism and inheritance.
In a Business’s .NET object hierarchy, the name of the Business is the top level namespace in a similar vein to the System namespace in the .NET Framework. The rest of the namespace hierarchy consists of functional and application sub systems. These should stay as close as possible to the standard namespaces that were implemented within the .NET Framework.
Even incredibly organized .NET namespace systems will not necessarily solve the problem, especially if the Business rules components do not contain the correct logic. There are a few vital things that all Business rule layers should contain. The components, for one thing, must always be self validating.
When Business logic components are built in to an SDK, that means you are effectively disconnecting it from your Web application, as well as any other input validation that it may perform. Thus, Business rules components should be the last line of defense to ensure that strictly valid values make their way in to the database.
Even in those instances when you have field constraints that have been implemented in to the database, it is still vital to validate input data as a means of throwing more informative custom exceptions to the component’s consumers.
In terms of database connectivity, each of the Business rules components that communicate with a database must inherit from a base class that implements a property for a database connection string. Since components may indeed be used by a number of different consumers, it is not good to have any connection string retrieval logic baked in to them. It is a lot better to have the consumer provide the necessary data at run time.
The user interface level of any application should always be free of ADO.NET – and that includes ASP.NET web applications. While ADO.NET might be a quality form of technology for the retrieval and manipulation of data, it does not work well when it comes to representing logical entities within an application.
Typed DataSets can be employed, but they are quite often a nightmare to manage. Instead, Business rules components should distill ADO.NET objects in to objects that are representative of the entities within your system. So say, for example, that you are retrieving a list of customers from your database.
When doing this, do not return a DataSet with customer data on it. Rather, create a typed collection of Customer object, and then pass that back. In the process of constructing the typed collection, one can also perform any other logic that was not performed initially by the stored procedure.
You should still be able to bind your typed collection as long as it manages to implement the IEnumerable interface. One should also be able to take advantage of custom properties, sub objects, and methods that have been implemented within the objects.
The Bottom Line
Ultimately, the code behind class for each of the ASP.NET pages must contain nothing more than the glue that binds a company’s Business rules SDK with the elements of the page, as well as the elements of the page to each other through event wire ups.
All the real logic that comprises the web application should be put in to a framework of Business rules components that may be re-used by a variety of different consumers, including web services, mobile devices, Windows Forms applications, and more.
A move to ASP.NET entails a lot more than merely changing a platform or technology that has been used in the past. It also means changing one’s mindset about the way in which an application has been constructed, and where its pieces should go.
