مزایای استفاده از BussinesLayer

[jaykob]

سلام دوستان

من یک پروژه ساده رو که با EntityFrameWork نوشته بودم این مرتبه یک CLassLiberary به نام BussinesLayer ایجاد کردم که یک کلاس واسه پروپرتی هام داره و یک کلاس هم که لیست کارمندان من رو برمی گردونه در ضمن با LINQ ارتباط با دیتابیس رو برقرار کردم و خوب توی کنترلم از اون BussinesLayer استفاده کردم و اطلاعات رو خوندم و داخل View نشون دادم می خوام اصول این روش رو بدونم که مزایاش چیه و معایبش و بهتره از EntityFramework استفاده بشه یا نه ...

ممنون

[hakim22]

مهمترین مزیتش همون چیزی هست که ASP MVC بر مبناش پایه گذاری شده و اون جدا سازی قسمتها مختلف کد از هم . حالا شما میتوانید کارهای مربوط به مدیریت بانک و کار با جداول اطلاعاتی رو از درون کنترلر ها خارج کنید و کنترلرهای بسیار ساده تر و خلوت تری داشته باشید که فقط به وظیفه ی اصلیشون که همان آماده سازی اطلاعات برای نمایش در View هست بپردازید.

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

[مهدی هادیان2]

بسم الله الرحمن الرحیم

مهمترین مزیتش همون چیزی هست که ASP MVC بر مبناش پایه گذاری شده و اون جدا سازی قسمتها مختلف کد از هم . حالا شما میتوانید کارهای مربوط به مدیریت بانک و کار با جداول اطلاعاتی رو از درون کنترلر ها خارج کنید و کنترلرهای بسیار ساده تر و خلوت تری داشته باشید که فقط به وظیفه ی اصلیشون که همان آماده سازی اطلاعات برای نمایش در View هست بپردازید.

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

[hakim22]

درست است که حجم کد نویسی زیاد میشه اما در نهایت پروژه نظم خیلی بیشتری داره و تغییر پذیری بیشتری داره. با استفاده از Ninject و ابزاری مثل Resharper و AutoMapper کار سریع تر از اونی که انتظار دارید پیش میره.

[jaykob]

مهمترین مزیتش همون چیزی هست که ASP MVC بر مبناش پایه گذاری شده و اون جدا سازی قسمتها مختلف کد از هم . حالا شما میتوانید کارهای مربوط به مدیریت بانک و کار با جداول اطلاعاتی رو از درون کنترلر ها خارج کنید و کنترلرهای بسیار ساده تر و خلوت تری داشته باشید که فقط به وظیفه ی اصلیشون که همان آماده سازی اطلاعات برای نمایش در View هست بپردازید.

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

خیلی ممنون توضیح خیلی خوب و قابل فهمی بود

برای شروع امکان داره مثل یک موضوع مثل دانشگاه با فرض اینکه فقط ما موجودیت های دانشجو و کلاس ها و درس رو داشته باشیم به چه شکل باید در Bussines Layer طراحی کرد ؟ من همیشه کد رو می نویسم و مشکلی هم ندارم اما بحث اینه که آخر مثل حرف شما نمی شه که کد تمیز باشه قابلیت توسعه زیادی داشته باشد و ...

اگر وقت دارید یک مثال ساده و عملی بزنید من موضوع برام جا بیوفته ممنون می شم

با تشکر

[hakim22]

در ASP MVC به صورت پیشفرض سه قسمت Controller و Model و View وجود داره. روشی که پیشنهاد میشه استفاده از دو لایه ی مجزا با نامهای Repository و Services است. معمولا به صورت دو پروژه ی مجزا در کنار پروژه ی اصلی اضافه میشه و به صورت Class Library هستند.

کار لایه ی Repository برقرار کردن ارتباط با بانک است، فقط و فقط همین. در واقعه در اینجا فقط از entityframework استفاده می کنید. یک مدل رو در بانک Add میکنید و بعد متد SaveChanges رو فرا میخوانید. بسیاری از متدهایی که در این کلاس تعریف می کنید شامل دو یا سه خط و افزودن و یا خواندن مدل از بانک را دارند. مثلا مدل Strudent دارید یک متد با عنوان AddStudent اضافه می کنید که و یک متد با نام GetStudents که یک Ienumerable<Student> باز می گرداند و به همین ترتیب.

از لایه ی سرویس برای روتوش لایه ی Repository استفاده میشه . مثلا یک دانشجو وقتی از Repository بیرون میاد رشته تحصیلیش با یک Id مشخص شده و شما برای نمایش اطلاعات به کاربر نیاز دارید عنوان رشته رو نمایش بدید. در لایه ی سرویس اینجور کارها انجام میشه. تبدیل تاریخ ها ، ترکیب مدل ها . در واقع معمولا برای هر جدول در بانک SQL یک کلاس Repository تعریف میشه ولی سرویس برای خدمات دهی به کنترلر هست و ممکنه از یک یا چند Repository استفاده کنه.

مقادیر بازگشتی از Services باید و بهتره به صورت ViewModel باشه و نه خود Model و عملا هیچوقت در کنترلر نیازی به خود Model ندارید. حتی اگر مدل ها رو در یک پروژه ی مجزا تعیف کنید نیازی نیست به کنترلر Reference داشته باشند. مگر حالت خاصی پیش بیاد.

هر کنترلر ممکنه از یک یا چند Service استفاده کنه ولی هیچ ارتباط مستقیمی با Repository نداره و اصولا هیچ Reference هم به Repository نیاز نداره.

در اینجا چند مشکل بوجود میاد. اول اینکه کلاسها زیاد میشوند و ساختن مداوم آنها با کلمه ی کلیدی new سرسام آور است و کد را خیلی پیچیده می کنید. اینجاست که ابزارهایی مثل Ninject وارد بازی میشوند و با Dependency Injection نمونه سازی از کلاسها را به عهده می گیرند. شما فقط بالای هر کلاس تعریف می کنید که به چه کلاسهایی وابسته است و Ninject هنگام اجرا کلاسهای مورد نیاز شما را Inject میکند.

مشکل دیگر Map کردن خصوصیت ها از Model به ViewModel است. شما همیشه میتوانید از عملگر = استفاده کنید ولی وقتی تعداد خصوصیتها زیاد باشد این کار هم دیوانه کننده است. کار AutoMapper کپی کردن خصوصیت های یک کلاس به کلاس دیگر است و عملا انتقال خصوصیت ها از مدل به ViewModel و بر عکس با یک خط کد نویسی انجام میشود.

* خیلی ها اصرار دارند که نیازی به جدا کردن Repository و Services نیست و فقط با لایه ی Services کارهای ارتباط با بانک رو انجام میدهند. خیلی وقتها قابل قبول است اما هدف اصلی ما که جدا سازی وظایف مختلف بود رو نقض میکند.

* لایه ی Services کمک میکنه خیلی سریع بتوانید از WebApi استفاده کنید. با استفاده از این ابزار برقرار کردن ارتباط بین Javascript و بانک SQL خیلی بهتر و سریعتر انجام میشود.