ארכיטקטורת שכבות בתכנה למתחילים

25 בJuly 2013

2 תגובות
כל תכנה שנפגוש בעולם האמיתי מבוססת על ארכיטקטורת שכבות כזאת או אחרת, המוכרת ביותר כמובן מוכרת בשם  Three-Tier-Application
ז”א שלש שכבות במבנה של DAL-BL-UI
היכרות עם המבנה, הרעיון והשיטה היא מאוד רלוונטית לכל פיתוח באשר הוא.
 
מה זה?
תבנית עיצוב בסיסית שמגדירה הפרדת האפליקציה ל שכבת נתונים, שכבת לוגיקה, ושכבת ממשק משתמש.
(כאמור בהגדרה הביסיסית, ככל שהתכנה מורכבת יותר ייתכנו שכבות נוספות)
למה זה טוב?
 
תחזוקה:
ניתן להחליף או לתקן מימוש פנימי של שכבה אחת בארכיטקטורה בלי לשנות שכבה אחרת.
נוחות פיתוח:
אדם אחד עובד על רכיב בתכנה, אדם אחר עובד על רכיב אחר, כל עוד שהחתימות זהות ניתן לשלב כוחות ולייעל זמני פיתוח.
בדיקות:
תקלה כלשהיא מבודדת בכל שכבה בנפרד, לדוגמא אם לא קיבלנו רשימת נתונים לתצוגה נבדוק קודם את שלב הביניים (שכבת הBL) אם הנתונים שם תקינים נדע בוודאות שגם ברמת שכבת הDAL הנתונים תקינים וכל שנותר הוא לפתור את התקלה ברמת הUI
שימוש חוזר:
נניח שהרכיבים BL + DAL אהובים עלינו ועובדים היטב, ניתן להחליף את פלטפורמת הUI לטכנולוגיה אחרת במינימום מאמץ.
אבטחה:
נוח יותר להגדיר Interface-API לשכבה מסויימת בלי לחשוף מבני נתונים, Logic או DATA שלא רלוונטי למשתמש, כמו גם חסימה בפני האקרים (רלוונטי יותר בטכנולוגיות WEB) ברמות שונות.
ניתן להגדיר רמות שונות של אינקפסולציה לשכבות ולקבל מבנה יעיל יותר. תכל’ס: נקבל מבנה שנראה בערך כך:
3T
שתי בעיות ניצבות עכשיו בפנינו,
1. מי מרים את מי? ז”א במודל של MVC (לא להתבלבל זה לא קשור למודל שלש שכבות, אולי דרך לממש תקשורת בין שכבות) משתמשים בקונטרולר ע”מ לתקשר בין שכבות .
הרעיון בבסיסו שלכל אובייקט מישהו צריך לעשות אתחול, בנוסף לקשר את התלויות, כי אם שכבת הUI תלויה בשכבת הBL וכן הלאה..
 
נצטרך מישהו שכן מכיר את כולם ומרים אותם לאוויר ומזריק את התלויות לפי
סדר. במקרה כזה מקובל להשתמש בקלאס (סטטי?) חיצוני שכל תפקידו להרים את האפליקציה בד”כ באמצעות חתימות של Contracts במבנה כזה או אחר.
2. אם ניצמד לרעיון שאין היכרות בין השכבות, הרי תמיד יש לנו מודל כלשהו שכולם מטפלים בו, זה אומר נצטרך להפריד את המודל לשכבה צדדית (DLL) שכולם רפרנס אליו ומשתמשים באותו המודל,
ולא שהמודל יושב בשכבת הDATA (הרי הUI לא מכיר את שכבת הDATA). זה בידיוק המקרה הקלאסי שבו מגדירים Contracts לפרוייקט שלנו וכל שכבה משתמשת במודל דרך חוזה משותף.
 
דוגמא בסיסית למבנה כזה בקוד C#:
/dll Common

namespace Contracts

{

   public interface IDemoService

   {

          Model CommonModel { get; set; }

   }

 

    public class Model

    {

    }

 

}

 

//dll DAL

namespace  Dal

{

    using Contracts;

 

    public class DataManager : IDemoService

    {

        public DataManager(Model model)

        {

            _dalModel = model;

        }

      

        private Model _dalModel;

       

        public Model CommonModel

        {

            get { return _dalModel; }

            set { _dalModel = value; }

        }

    }

 

}

 

//dll BL

namespace  BL

{

    using Contracts;

    using Dal;

 

    public class Logic : IDemoService

    {

 

        private DataManager _blDataManager;

        private Model _bllModel;

 

        public Model CommonModel

        {

            get { return _bllModel; }

            set { _bllModel = value; }

        }

 

 

        public Logic( Model model)

        {  

            _bllModel = model;

            _blDataManager = new DataManager(this._bllModel);

        }

    }

 

 

}

 

//dll UI

 

namespace  UI

{

    using Contracts;

    using BL;

 

    public class Client : IDemoService

    {

        private Logic _logic;

 

        private Model _clientlModel;

 

        public Model CommonModel

        {

            get { return _clientlModel; }

            set { _clientlModel = value; }

        }

 

        public Client()

        {

            _clientlModel = new Model();

            _logic = new Logic(this._clientlModel);

        }

    }

 

}

 

 

הוסף תגובה
facebook linkedin twitter email

Leave a Reply

Your email address will not be published. Required fields are marked *

2 תגובות

  1. kindle-google26 בJuly 2013 ב 9:38

    עזר לנו מאוד. >ודה רבה

    Reply
  2. J28 בJuly 2013 ב 7:25

    מקצועי ומאוד ברור.
    סחתן.
    תודה

    Reply