PDA

توجه ! این یک نسخه آرشیو شده میباشد و در این حالت شما عکسی را مشاهده نمیکنید برای مشاهده کامل متن و عکسها بر روی لینک مقابل کلیک کنید : لایه نویسی استاندارد



آبجی
14th February 2010, 12:50 AM
کمتر کسی هست که حداقل، واژه ی برنامه های چند لایه به گوشش نخورده باشه.
قبلا یک پست در این مورد در این وبلاگ نوشته بودم که فقط مفاهیم اولیه ی این تکنیک رو توضیح میداد و حال در چند پست (که البته نمی دونم چند تا میشه!) قصد دارم تا جنبه ی حرفه ای اون رو بررسی کنم و در نهایت قسمتی از یک پروژه رو با این معماری به شکلی حرفه ای و زیبا پیاده سازی کنیم.
قبل از شروع باید بگم که این تکنیک استاندارد خاصی نداره و هر کسی به روشی که دوست داره اون رو پیاده سازی می کنه. در حقیقت، تفاوت در جزئیات هست نه در کلیات.
روشی که در این چند پست می خونید، روشی هست که من ازش استفاده می کنم و این روش رو با بررسی چندین پروژه ی بزرگ و در طی چندین سال کار بر روی پروژه های مختلف انتخاب کردم. به طور کلی برنامه های چند لایه به سه بخش تقسیم میشن. لایه ی مرتبط با داده ها (DAL)، لایه ی منطقی (BLL) و لایه ی نمایش (PL)
ابتدا در مورد DAL توضیح میدم.
برای DAL نیاز به یک کلاس پایه برای تمامی کلاس های DAL دیگه وجود داره. این کلاس پایه یک کلاس abstract هست.
کلاس های abstract کلاس هایی هستند که متدها و خواص عمومی رو برای بقیه ی کلاس هایی که از اونها به ارث میبرن تعریف می کنن.
برای متدهای کلاس های abstract بر خلاف اینترفیس ها میشه کد نوشت. کد نویسی برای خواص و متدهای کلاس های abstract دلخواهه اما اعضای یک اینترفیس نمی تونن هیچگونه کدی در بدنشون داشته باشن.
درک مفهوم کلاس های abstract و interface ها برای پیاده سازی پروژه های بزرگ و چند لایه واقعا نیاز هست. بنابراین سعی کنید در مورد اونها مطالعه ی بیشتری داشته باشید.
تعداد کلاس های DAL بستگی به تعداد موجودیت ها داره. مثلا یک موجودیت مثل مشتری یک کلاس DAL مختص خودش داره. اما همین کلاس از کلاس پایه ی abstract ای که قبلا اشاره شده ارث می بره. این کلاس abstract، اعمال و خواص متداولی که برای کار با داده ها از اونها استفاده میشه رو در بر داره. به عنوان مثال، خاصیت Connection String و یا متدهای شی DbCommand که برای اجرای یک دستور SQL استفاده میشن. مثل ExecuteNonQuery و ExecuteReader و …
اگر با MS Data Application Block آشنا باشید، اون رو می تونید به عنوان همین کلاس abstract در نظر بگیرید و ازش استفاده کنید! کلاس کاملیه و بسیار خوب نوشته شده.
توضیحات فوق رو در قالب شبه کد در ذیل می بینید:


abstract class DataAccess

{

protected int ExecuteNonQuerty(DbCommand cmd)

{

// do something

return cmd.ExecuteNonQuerty();

}

}
abstract class MyDalObj: DataAccess

{

public acstract bool DeleteRecord(int id);

}


public class MySqlDalObj: MyDalObj

{

public override bool DeleteRecord(int id)

{

SqlCommand cmd = new SqlCommand(...);

int result = ExecuteNonQuery(cmd);

return (result == 1);

}

}
فراخوانی متد ExecuteNonQuery در کلاس MySqlDalObj، این متد رو از کلاس پایه ی DataAccess فراخوانی می کنه.

آبجی
14th February 2010, 12:50 AM
در قسمت قبل شکلی از نحوه ی ایجاد معماری چند لایه (که البته دلخواه من هست!) رو دیدید.
یکی از دلایل پیاده سازی چنین سطحی از به ارث بری، آینده نگری برای تغییر دیتابیس سیستم هست. فرضاً اگر قصد داشته باشید که دیتابیس برنامه رو از SQL Server به MySql تغییر بدید، تنها کار مورد نیاز، ایجاد کلاسی هست که از MyDalObj ارث ببره. بقیه ی تنظیمات مثل Connection String، میزان دلخواه زمان Cache داده ها و … از DataAccess خونده میشن و نیازی به نوشتن مجدد اونها ندارید!
و یا اگر نیاز باشه که یک دیتابیس به طور مشترک توسط چند سیستم استفاده بشه، هر DAL در آخرین سطح (مثل کلاس MySqlDalObj) می تونه پارامتری رو به عنوان نام SP ای که اطلاعات اون سیستم در اون نگهداری میشه بپذیره.
خلاصه اینکه در این روش، تغییرات آتی در سیستم به راحتی و با کمترین کد نویسی امکان پذیر هست. و اما در مورد کلاس های BLL:
داده های برگشتی توسط کلاس های DAL، داده های خام یا اصطلاحا RAW Data هستند. این داده ها باید به شکلی به داده های قابل فهم تبدیل بشن، روی اونها پردازش های نهایی صورت بگیره و در نهایت در اختیار لایه نمایش قرار بگیرن.
این پردازش که می تونه شامل اعمال محاسباتی و تصدیق صحت داده ها از نظر فرمت و جامعیت باشه توسط BLL صورت می گیره. البته در نظر داشته باشید که در حال شرح فرایندی هستیم که داده ها از سرور به کلاینت ارسال میشن وگرنه این داستان برای ارسال داده ها از کلاینت به سرور هم صدق می کنه.
یکی دیگه از وظایف BLL، تغییر شکل داده ها به صورتی هست که برای لایه ی UI یا DAL قابل فهم باشه. این قابل فهم بودن با تبدیل داده ها به موجودیت هایی از همون نوع به وجود میاد. به عبارت ساده تر، برای هر موجودیت نیاز به ایجاد یک کلاس هست که این کلاس خصوصیات موجودیت رو در بر میگیره.
فرضاً اگر قصد Update کردن اطلاعات موجودیتی مثل مشتری شامل نام و نام خانوادگی با آی دی ۳ رو داشته باشیم، کلاسی با نام مشتری با دو خصوصیت به نام های FirstName و LastName و یک متد با نام Update داریم:
Customer cust;
cust.ID = 3
cust.FirstName = “Behrouz”;
cust.LastName = “Rad”;
cust.Update();

استفاده از تمامی مطالب سایت تنها با ذکر منبع آن به نام سایت علمی نخبگان جوان و ذکر آدرس سایت مجاز است

استفاده از نام و برند نخبگان جوان به هر نحو توسط سایر سایت ها ممنوع بوده و پیگرد قانونی دارد