Base Classes
"Wisdom consists of the anticipation of consequences." - Norman Cousins
The base classes encapsulate all of the properties and methods commonly needed by the derived domain classes in an application. These abstract classes are the parent classes that cannot be instantiated on their own, but they do allow their concrete derived children to inherit common methods and properties.
Programmers can derive concrete domain classes from these high-level base classes even though some of them might not totally understand the technical concepts behind abstract classes and inheritance. Developers can incorporate sophisticated methods and properties in devrived concrete classes without having to learn the underlying concepts behind the base class code.
Abstract classes can either act like interfaces or regular classes since they can define behaviors and attributes, and they can provide implementation details, but are not required to do so. If an abstract class does not provide implementation details, domain-specific concrete classes that inherit from the abstract class are required to provide the implementation code.
With abstract and interface classes, the collaboration among an application's components relies on mutual obligations required of them and benefits derived by each. Components interact through the guarantees provided by each based on the concept of a contract. For example, behaviors or methods inherited from base classes can define input parameter datatypes, return datatypes, preconditions, and postconditions.
While both abstract classes and interfaces support separating contract from implementation, interfaces cannot specify new behaviors and attributes in later revisions. Abstract classes can add members as needed to support additional functionality. Since frequent versioning is an integral part of constantly changing technological and business needs of an application, the abstract class became the model for all base classes in this architecture where cross-domain class functionality is commonly needed.
Visual Studio Team System 2010 Ultimate edition produced the following class diagram for the architectural framework. The Architecture overview covered the BLL, BP, DAL, and MP base classes. As shown below, these classes are the base class from which most concrete domain classes are derived.
The DALFactory, IDAL, and DataProvider are classes and interfaces utilized in the framework by the Data Access Layer (DAL) to connect to and retrieve resultsets from a data store via parameters and a stored procedure. These simple data access classes were derived from Implementing a Data Access Layer in C# by Joydip Kanjilal presented in the ASPAlliance website. There are four major ADO.NET data providers: SQL Server, Oracle, Odbc, and OleDB Data Providers. The data providers consist of four ADO.NET classes: Connection, Command, Data Reader, and Data Adapter. These data provider classes implement the following interfaces: IDbConnection, IDataReader, IDbCommand, and IDbDataAdapter.
The CheckinOutBLL and CheckinOutDAL were contributed by Kenneth Weems to check in records that were checked out by the user for editing. The Application and AppDataContract classes allow an application to store encrypted connections strings in an application variable to allow only the client to access information in the database. The Application class is used in OOP applications and The AppDataContract is utilized by an Application service to provide the application variable loaded from the Global.asax upon startup.
The CSM class is for handling customer service messages stored in a database table, and the ErrorLoggerBLL and ErrorLoggerDAL classes provide error handling for page code-behind try-catch-finally blocks (Thanks to Jeremy Wilberger and Kenneth Weems for their input). Try-catch-finally blocks only occur in the code-behind classes and not in the BLL or DAL classes since ASP.NET error bubbling will allow the application to know that the kind of error and where it occurred.