General and Architectural Project Practices (Part 2)
Design Patterns
Using
design patterns would definitely organize and separate your program code neatly,
whereas having multiple tiers (n-tier architecture) or at least a three tier
architect design pattern would split your project code into main three tiers,
which are:
- Data Access Layer (DAL)
- Business Logic Layer (BLL)
- Presentation Layer (PL)
Such
code separation is vital to organize your code, and makes it easily
maintainable. Additionally bug fixing would be less messy, whereas you can
identify which layer have generated the bug, depending on the code flow or the
exception you get, whether it’s a database related (DAL) or logic related (BLL)
or entry related (PL).
Furthermore,
separating your Data Access Layer – properly – would imply ACID, which stands for Atomicity,
Consistency, Isolation and Durability, however in this
blog we are more concerned about isolation, which is a vital property that
makes your code easily replaced, in case the back end source (database) have
been changed, which in most cases leaves the BLL and PL intact.
File Grouping
Applying
a design pattern as per the previous practice would imply files grouping;
however this would be a general grouping, but grouping files based on their
relativity within the same tier (layer) using folders, would add more order and
systemization to your code files. Whether your code is extended throughout the different
tiers (layers) or it’s located in one tier, this is a good practice to order
and locate your code files in your project based on their relativity.Partial Classes
Is
basically splitting the definition of a class over two or more source files
whereas each source file contains a section of the class definition, and all
parts are combined when the application is compiled.
When
working on large projects, spreading a class over separate files allows
multiple programmers to work on it simultaneously, thus giving the class a high
maintainability value.
Additionally,
applying partial classes would split your code logic in a way that your
different code sections can be spread and organized over multiple source files,
instead of having all the sections in one big file (class).
Nevertheless,
over using partial classes would lead to branching your class over multiple
files, where you will lose track of your class building blocks. Use partial
classes wisely, reasonably and effectively.
The
following is an example on one of the good practices when using partial classes,
applying the below practice would leave the genuine properties of your object
intact, while giving a new work place (partial class) for your continuous
modification and changing logic, thus leaving the original object properties
un-tampered with, somewhat minimizes bugs and errors.
Defining object properties and/or constructors – for a business object most probably – would reside on a separate file as part of the class:
public partial class Employee
{
public int ID
{
get;
set;
}
public string FirstName
{
get;
set;
}
public string LastName
{
get;
set;
}
public Employee(int id, string firstName, string lastName)
{
this.ID = id;
this.FirstName = firstName;
this.LastName = lastName;
}
public Employee(string firstName, string lastName)
{
this.FirstName = firstName;
this.LastName = lastName;
}
}
public partial class Employee
{
public string
FullName
{
get
{
return this.FirstName
+ " " + this.LastName;
}
}
public decimal
CalcualteNetSalaryAfterTaxById(int id)
{
// Do some logic here
}
public int
GetVacationBalanceById(int id)
{
// Do some logic here
}
}Continue Reading (Part 3) >>>
Comments
Post a Comment