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;
       }
    }
While the object methods along with its extended properties (not a genuine property from the source) would reside on another file as part of the same class:
      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

Popular posts from this blog

Machine Learning Explained!

Image
The minute we hear the word machine learning, many thoughts rush into our minds, starting from high-tech robotics, sophisticated complex algorithms and ending by Sci-fi movies (of course!). Well, we might be partially right if the plan is to assemble a robot or reinvent an auto-pilot car, but this is no longer the case these days! In the recent years, Machine Learning is being widely used in business scenarios or – to be fair – it’s even becoming mainstream! Predictive machine learning modules and/or sentiments are being used in our day-to-day tools and utilities. For example, there are off-the-shelf SaaS sentiments to tell whether a tweet from a customer is a good feedback (happy customer) or a bad feedback (unhappy customer). Another example that we could find off-the-shelf is face recognition, which is a service we could feed with a couple of (face) photos of a person, and then feed a totally different photo – of the same person – other than the ones provided at the begin...
Read more

Building JSON Objects in Microsoft Flow

Image
A couple of days ago, I was helping a friend with a case in Microsoft Flow ... So I thought this is a good time to write a new article that would be a reference for my friend, and hopefully others would find this useful if they came across the same issue. The Case It's very simple and straight forward, we have a flow that gets initiated once an item is added to a SharePoint list, and we want to return a JSON object of the newly added item ... Easy! Good to know... Now before going into the solution, it's good to know that Microsoft Flow itself handles data within as JSON, whereas Flow is not only a process automation service, it's an integration service as well. Therefore it needs a common ground/language/format - you name it - to handle all data types from all the different sources (SharePoint list, SQL Table, Excel, etc...) This is How... Well, there are two different ways to tackle the case above, and I'm going to list them both in this article....
Read more

Microsoft Flow as a Service for Custom Applications

Image
I've been so eager to write about Microsoft Flow since I have started using it about a year ago! However, I've seen a lot of articles out there by community contributors talking about almost every single capability that Flow can do ... In addition, I personally believe that the Microsoft Flow team is doing a good job putting people on the right learning track. There are many scenarios that we could consider using Flow with, however in this very post I'll be writing about when to consider Flow while building custom developed applications ... Flow could be your "LEGO"  building block for almost every application! As developers, almost every single one of us have developed against at least one API, and I surely believe that many have developed APIs that connects to third party services and/or social media ... Now, this task is usually a bit costly during the project, whereas developers have to go through the technical documentation for those APIs and absorb th...
Read more