پیاده سازی صحیح برنامه به صورت سه لایه

[csharpcollegian]

سلام وقت به خیر
دوستان من یک برنامه به صورت سه لایه نوشتم که یک قسمتش وظیفه انتشار و ثبت بن خرید برای کارمندان شرکت رو بر عهده داره
ثبت اطلاعات بن خرید به این صورت انجام میشه که اطلاعات در لایه نمایش (Presentation Layer) گرفته میشه و به لایه منطق تجاری (Business Logic Layer) ارسال میشه :

private void button1_Click(object sender, EventArgs e)
{
    BonClass Obj = new BonClass();
    Obj.PersonnelID = textBox1.Text;
    Obj.Description = textBox2.Text;
    .
    .
    .
    Obj.Insert();
}

بعد در لایه منطق تجاری اطلاعات توسط لایه دسترسی به داده (Data Access Layer) در دیتابیس ثبت میشه :

class BonClass
{
    DataAccessLayer DAL = new DataAccessLayer();
    .
    .
    .
    public void Insert()
    {
        SqlParameter personnelIDParam = new SqlParameter("@PersonnelID", this.PersonnelID);
        SqlParameter descriptionParam = new SqlParameter("@Description", this.Description);
        .
        .
        .
        DAL.ExecuteCommand("procBonInsert", CommandType.StoredProcedure, personnelIDParam, descriptionParam, ...);
    }
    .
    .
    .
}

برنامه باید قبل از ثبت بن خرید چک کنه که قبلا برای این کارمند بن خرید دیگه ای ثبت نشده باشه بعدش بن جدید رو ثبت کنه (هر کارمند فقط حق داشتن یک بن خرید در ماه رو داره)
من همیشه این جور شرط ها رو داخل لایه منطق تجاری و همون متد Insert پیاده سازی می کنم که زمانی که متد Insert در لایه نمایش صدا زده شد، تمامی شروط به صورت اتوماتیک چک بشن بعدش عمل Insert انجام بشه :

class BonClass
{
    DataAccessLayer DAL = new DataAccessLayer();
    .
    .
    .
    public void Insert()
    {
        Checking Conditions //بررسی اینکه آیا قبلا بن خریدی برای کارمند ثبت شده یا نه
        .
        .
        .
        if(Conditions true)
        {
            SqlParameter personnelIDParam = new SqlParameter("@PersonnelID", this.PersonnelID);
            SqlParameter descriptionParam = new SqlParameter("@Description", this.Description);
            .
            .
            .
            DAL.ExecuteCommand("procBonInsert", CommandType.StoredProcedure, personnelIDParam, descriptionParam, ...);
        }
   }
    .
    .
    .
}

دلیلم واسه این کار اینه که اینجوری منطق اصلی برنامم در کلاس هام (لایه منطق تجاری) پیاده سازی میشه و دیگه در لایه نمایش درگیر مسائلی که مربوط به منطق برنامه هست نمیشم و فقط اعتبار سنجی انجام میدم
حالا سوالم از دوستان و اساتید محترم اینه که آیا این روشی که من به کار بردم(بررسی شروط در همان لایه منطق تجاری و متد Insert)، معماری سه لایه رو به صورت اصولی و صحیح پیاده می کنه و منطبق بر مفاهیم معماری سه لایه هست یا نه ؟
چون یکی از دوستان میگفت باید این شرط رو در همان لایه نمایش چک کنی، چون بررسی این شرط هم یه جور اعتبار سنجیه !
ولی از نظر من اینجوری لایه نمایش هم درگیر منطق برنامه میشه که درست نیست...!
دوستان ممنون میشم نظراتتون رو مطرح کنید

 

[the_king]

سلام وقت به خیر
دوستان من یک برنامه به صورت سه لایه نوشتم که یک قسمتش وظیفه انتشار و ثبت بن خرید برای کارمندان شرکت رو بر عهده داره
ثبت اطلاعات بن خرید به این صورت انجام میشه که اطلاعات در لایه نمایش (Presentation Layer) گرفته میشه و به لایه منطق تجاری (Business Logic Layer) ارسال میشه :

بعد در لایه منطق تجاری اطلاعات توسط لایه دسترسی به داده (Data Access Layer) در دیتابیس ثبت میشه :

برنامه باید قبل از ثبت بن خرید چک کنه که قبلا برای این کارمند بن خرید دیگه ای ثبت نشده باشه بعدش بن جدید رو ثبت کنه (هر کارمند فقط حق داشتن یک بن خرید در ماه رو داره)
من همیشه این جور شرط ها رو داخل لایه منطق تجاری و همون متد Insert پیاده سازی می کنم که زمانی که متد Insert در لایه نمایش صدا زده شد، تمامی شروط به صورت اتوماتیک چک بشن بعدش عمل Insert انجام بشه :
دلیلم واسه این کار اینه که اینجوری منطق اصلی برنامم در کلاس هام (لایه منطق تجاری) پیاده سازی میشه و دیگه در لایه نمایش درگیر مسائلی که مربوط به منطق برنامه هست نمیشم و فقط اعتبار سنجی انجام میدم
حالا سوالم از دوستان و اساتید محترم اینه که آیا این روشی که من به کار بردم(بررسی شروط در همان لایه منطق تجاری و متد Insert)، معماری سه لایه رو به صورت اصولی و صحیح پیاده می کنه و منطبق بر مفاهیم معماری سه لایه هست یا نه ؟
چون یکی از دوستان میگفت باید این شرط رو در همان لایه نمایش چک کنی، چون بررسی این شرط هم یه جور اعتبار سنجیه !
ولی از نظر من اینجوری لایه نمایش هم درگیر منطق برنامه میشه که درست نیست...!
دوستان ممنون میشم نظراتتون رو مطرح کنید

کاری که شما انجام می دهید درست است، اون اعتبار سنجی که داخل لایه نمایش انجام میشه یک اعتبار سنجی مقدماتی برای تطابق نوع و فرمت ورودی ئه، نه اعتبار مقدار ورودی.
در حدی است که نیازی به ارتباط با لایه دسترسی به داده نباشه، مثلا اینکه textBox1 رشته تهی نباشه یا آدرس ایمیل حتما شامل یک کاراکتر @ باشه.
همانطور که در صفحات وب موقع Login کردن وقتی نام کاربری تهی باشه در همان صفحه لاگین با یک کد javascript به کاربر اخطار داده میشه و سراغ سرور و جدول مشخصات کاربران نمیره.

وگرنه وقتی یک موردی بررسی میشه که با لایه دسترسی به داده در ارتباط ئه، و نیاز به دریافت اطلاعات پایگاه داده است، دیگه نباید لایه منطق تجاری رو این وسط دور بزنید و نادیده بگیرید.

 

[csharpcollegian]

کاری که شما انجام می دهید درست است، اون اعتبار سنجی که داخل لایه نمایش انجام میشه یک اعتبار سنجی مقدماتی برای تطابق نوع و فرمت ورودی ئه، نه اعتبار مقدار ورودی.
در حدی است که نیازی به ارتباط با لایه دسترسی به داده نباشه، مثلا اینکه textBox1 رشته تهی نباشه یا آدرس ایمیل حتما شامل یک کاراکتر @ باشه.
همانطور که در صفحات وب موقع Login کردن وقتی نام کاربری تهی باشه در همان صفحه لاگین با یک کد javascript به کاربر اخطار داده میشه و سراغ سرور و جدول مشخصات کاربران نمیره.

وگرنه وقتی یک موردی بررسی میشه که با لایه دسترسی به داده در ارتباط ئه، و نیاز به دریافت اطلاعات پایگاه داده است، دیگه نباید لایه منطق تجاری رو این وسط دور بزنید و نادیده بگیرید.

جناب the_king ممنونم از پاسختون ولی یک سوال دیگه داشتم از خدمتتون
یکی از اساتید وقتی کد من رو دید گفت برای پیاده سازی برنامه سه لایه حتی حق ندارم از کلاس sqlParameter در لایه بیزینس استفاده کنم !
ایشون نظرشون این بود که در معماری سه لایه برای هر موجودیت(کلاس) در لایه بیزینس باید یک کلاس هم در لایه ی داده طراحی بشه !
یعنی هر کلاس لایه داده، عملیات (CRUD) کلاس متناظر خودش در لایه بیزینس رو انجام میده !
ولی من تا به امروز یک کلاس واحد برای لایه داده طراحی می کردم که تمامی کلاس های لایه بیزینس از اون استفاده می کردن، (یک نمونه ساده از کد خودم رو پیوست کردم ممنون میشم بررسی کنید)
اگر ممکنه میخوام نظر شما رو هم بدونم
خیلی ممنون

 

[the_king]

جناب the_king ممنونم از پاسختون ولی یک سوال دیگه داشتم از خدمتتون
یکی از اساتید وقتی کد من رو دید گفت برای پیاده سازی برنامه سه لایه حتی حق ندارم از کلاس sqlParameter در لایه بیزینس استفاده کنم !
ایشون نظرشون این بود که در معماری سه لایه برای هر موجودیت(کلاس) در لایه بیزینس باید یک کلاس هم در لایه ی داده طراحی بشه !
یعنی هر کلاس لایه داده، عملیات (CRUD) کلاس متناظر خودش در لایه بیزینس رو انجام میده !
ولی من تا به امروز یک کلاس واحد برای لایه داده طراحی می کردم که تمامی کلاس های لایه بیزینس از اون استفاده می کردن، (یک نمونه ساده از کد خودم رو پیوست کردم ممنون میشم بررسی کنید)
اگر ممکنه میخوام نظر شما رو هم بدونم
خیلی ممنون

در خیلی موارد دیگه هم چنین حالتی پیش میاد، خیلی از کمیت ها مثل کارایی، امنیت، نگهداشت پذیری، استفاده مجدد پذیری و ... روی همدیگر تاثیر دارند. وقتی سعی می کنید یک کمیت
رو تقویت کنید یک کمیت دیگر را تضعیف خواهید کرد، هیچ راهی وجود نداره که تمامی کمیت ها را با هم بهبود بدید. اگر یک تعادلی در رعایت قواعد نباشه حتی بدیهی ترین اصول برنامه نویسی
هم خودشون به محصول آسیب می رسونند.

مساله اینه که زبانی مثل #C و Net Framework. یکسری امکاناتی برای تعامل با پایگاه داده ارائه می کنه که مبتنی بر شیء گرایی است، اما معماری اش سه لایه ای نیست.
آداپتور ای که ارتباط شما رو با پایگاه داده برقرار می کنه میاد جزئی از فرمی میشه که در لایه نمایش قرار داشت. طبیعتا هر چقدر از این امکاناتی که برای سرعت بخشیدن به طراحی
وجود دارند بیشتر استفاده کنید از معماری سه لایه دور تر می شوید. محیط ویژوال استدیو خودش شما رو به سمتی هدایت می کنه که لایه ها با هم تداخل پیدا کنند.

معماری سه لایه یکسری مزیت ها ایجاد می کنه و یکسری معایب. و از آنجایی که طراحی محیط برنامه نویسی با معماری سه لایه منطبق نیست هر تلاشی برای تطابق بیشتر
حجم کد رو بیشتر می کنه. حجم کد که بیشتر شد، کارایی نرم افزار، پیچیدگی، نگهداشت پذیری و ... هم تضعیف می شوند.

شما می توانید دو تا هدف متفاوت داشته باشید، یک هدف اینه که تا حدی که از خروجی محصول تون انتظار میره از مزایای معماری سه لایه برای بهبود کیفیت نرم افزار کمک بگیرید، یعنی
تا حدی معماری سه لایه رو اعمال کنید که کیفیت محصول رو به حد مطلوب تون برسونه.
هدف دوم اینه که تا جایی که تمامی اصول معماری سه لایه رعایت بشه کد برنامه تون رو تغییر بدهید، یعنی رعایت صریح تمامی قواعد معماری سه لایه جزو انتظارات شما باشه.
طبیعتا وقتی اصول معماری سه لایه برای شما مهمتر از کارایی و زمانی که صرف کد نویسی می کنید باشه ناچارید مواردی رو به کد اضافه کنید که روی کارایی و هزینه تاثیر منفی میذاره.
اگر کاری رو برای تحویل دادن به یک استاد آماده می کنید، اختیاری در تصمیم گیری ندارید، وگرنه در برنامه نویسی تجاری معماری ها رو برای بهبود فرایند بکار می برند، هدف قرار نمی دهند.

 

[csharpcollegian]

در خیلی موارد دیگه هم چنین حالتی پیش میاد، خیلی از کمیت ها مثل کارایی، امنیت، نگهداشت پذیری، استفاده مجدد پذیری و ... روی همدیگر تاثیر دارند. وقتی سعی می کنید یک کمیت
رو تقویت کنید یک کمیت دیگر را تضعیف خواهید کرد، هیچ راهی وجود نداره که تمامی کمیت ها را با هم بهبود بدید. اگر یک تعادلی در رعایت قواعد نباشه حتی بدیهی ترین اصول برنامه نویسی
هم خودشون به محصول آسیب می رسونند.

مساله اینه که زبانی مثل #C و Net Framework. یکسری امکاناتی برای تعامل با پایگاه داده ارائه می کنه که مبتنی بر شیء گرایی است، اما معماری اش سه لایه ای نیست.
آداپتور ای که ارتباط شما رو با پایگاه داده برقرار می کنه میاد جزئی از فرمی میشه که در لایه نمایش قرار داشت. طبیعتا هر چقدر از این امکاناتی که برای سرعت بخشیدن به طراحی
وجود دارند بیشتر استفاده کنید از معماری سه لایه دور تر می شوید. محیط ویژوال استدیو خودش شما رو به سمتی هدایت می کنه که لایه ها با هم تداخل پیدا کنند.

معماری سه لایه یکسری مزیت ها ایجاد می کنه و یکسری معایب. و از آنجایی که طراحی محیط برنامه نویسی با معماری سه لایه منطبق نیست هر تلاشی برای تطابق بیشتر
حجم کد رو بیشتر می کنه. حجم کد که بیشتر شد، کارایی نرم افزار، پیچیدگی، نگهداشت پذیری و ... هم تضعیف می شوند.

شما می توانید دو تا هدف متفاوت داشته باشید، یک هدف اینه که تا حدی که از خروجی محصول تون انتظار میره از مزایای معماری سه لایه برای بهبود کیفیت نرم افزار کمک بگیرید، یعنی
تا حدی معماری سه لایه رو اعمال کنید که کیفیت محصول رو به حد مطلوب تون برسونه.
هدف دوم اینه که تا جایی که تمامی اصول معماری سه لایه رعایت بشه کد برنامه تون رو تغییر بدهید، یعنی رعایت صریح تمامی قواعد معماری سه لایه جزو انتظارات شما باشه.
طبیعتا وقتی اصول معماری سه لایه برای شما مهمتر از کارایی و زمانی که صرف کد نویسی می کنید باشه ناچارید مواردی رو به کد اضافه کنید که روی کارایی و هزینه تاثیر منفی میذاره.
اگر کاری رو برای تحویل دادن به یک استاد آماده می کنید، اختیاری در تصمیم گیری ندارید، وگرنه در برنامه نویسی تجاری معماری ها رو برای بهبود فرایند بکار می برند، هدف قرار نمی دهند.

کاملا متوجه حرفتون شدم و خیلی خیلی ازتون ممنونم
پس با این حساب چون دارم برنامه رو برای اهداف تجاری آماده می کنم، فکر می کنم همین سبک کد نویسی ای که براتون یک نمونش رو گذاشتم ادامه بدم بهتره
متشکرم بابت وقتی که گذاشتین