مثال برای برنامه نویسی چند لایه با استفاده از entity framework

سلام
مثالی برای برنامه نویسی چند لایه با استفاده از entity framework میخاستم.

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

سلام
من هم همین سوال را دارم من قبلا یه برنامه سه لایه با استفاده از ado.net نوشتم و میخواستم دیگه با entity framework کار کنم
حالا یعنی وقتی از entity framework برای کار با دیتابیس استفاده می کنیم دیگه لازم نیست به صورت سه لایه برنامه بنویسیم؟
اخه توی همین سایت چندتا اموزش دیدم که با استفاده از entity framework به صورت سه لایه برنامه نویسی میکردند؟

یک برنامه سه لایه رو در نظر بگیرید که از لایه های زیر تشکیل شده:

1. (DAL(Data Access Layer: لایه دسترسی به داده ها
2. (BLL(Business Logic Layer: لایه پردازش های مورد نیاز و اعتبارسنجی داده ها
3. (PL(Presentation Layer: لایه رابط کاربری برنامه

Entity Framework در حقیقت همون لایه DAL ما میشه. قبلا از Entity Framework استفاده نمیکردیم خودمون تو ADO.NET کد DAL رو مینوشتیم حالا Entity Framework این بخش رو از رو دوشمون برداشته که البته میشه گفت سنگین ترین بخشش هم هست!

پس مثلا ما اگر میخواهیم کد insert را بنویسیم وقتی یه دکمه روی فرم گذاشتیم تمام کدهای وارد کردن و اعتبارسنجی و غیره را در همان رویداد کلیک دکمه بنویسیم دارسته؟

به نظر من درسته؛ البته در نظر داشته باشید که معمولا کد اعتبارسنجی و پردازش های خاص رو هم به صورت کلاس در میارن و روی رویداد دکمه در نهایت تمام اینها اجرا میشن.

negar@ : ترجیح دادم باقی مکالمات در این زمینه رو در این بخش مطرح کنم.

-ارتباط چند لایه نویسی با Entity Framework:
از لایه ها بطور کلی (جدای از تمام محاسن دیگری که دارد) برای تفکیک کد و مرتب کردن و نظم بخشیدن برنامه استفاده می شه تا در مراجعات بعدی به کد برنامه نویس دچار سردرگمی نشود. اما این تفکیک کد تا چه حدی انجام شود بستگی به نوع پروژه دارد و نسخه یکسانی وجود ندارد.
بنابراین چند لایه نویسی یک مفهوم ساده و بدیهی هست که یک برنامه نویس مبتدی بعد از مدتی کدنویسی نیاز اون رو حس می کنه و حتی در صورت نداشتن تخصص کافی ، تا حدی و ناخودآگاه این کار رو انجام می ده.
معمولا در پروژه های ما database‌ وجود داره و برای ارتباط با اون نیاز به مجموعه ای کد هست. برنامه نویس برای نظم بیشتر و تفکیک کد، این مجموعه کد رو در قسمتی جداگاه قرار می ده تا از تکرار کد جلوگیری کنه و از طرفی خودشو ملزم به این می کنه که برای ارتباط با database‌ از این کدها استفاده کنه! در حقیقت این جمله آخری یعنی اینکه لایه ای رو Database تشکیل داده و دیگه بطور مستقیم با اون کار نمی کنه. این لایه به DataAccess‌ معروفه.
خوب حالا به نظر شما اگر این برنامه نویس از EF‌استفاده کنه دیگه نیاز به چند لایه نویسی نیست! البته که هست در حقیقت EF‌که کار با database‌رو تسهیل می کنه همون لایه DataAccess‌ هست.

- آیا لایه های دیگری نیاز هست؟
بستگی به نوع پروژه و حجم اون داره. هرچی حجم پروژه بزرگتر باشه و روابط بین موجودیت ها پیچیده تر باشه باز شما نیاز به تفکیک کردن و نظم بیشتر دادن دارین در نتیجه نیاز دارین لایه های بیشتری ایجاد کنید. البته به این نکته دقت کنید که بدون دلیل نباید لایه ایجاد کنید.

برای ایجاد لایه جدید مثالی می زنم. فرض کنید شما یک سری قوانینی باید در پروژه رعایت کنید که قوانین اون سیستمی هست که قراره شما مکانیزه کنید و از طرف مشتری یا کارشناس اون حوزه به شما داده می شه.
بطور مثال شما سیستم انتخاب واحد دانشگاه رو می خواین مکانیزه کنید و یک قانون این هست که دانشجویی که مشروط شده در ترم بعد امکان انتخاب بیش از 12 واحد رو نداره
یا اینکه سیستم فروش رو پیاده سازی می کنید و در بخش فاکتور اگر خریدی بیش از 50 هزار تومان بود می بایست 5٪ تخفیف محاسبه شود.
اینها یک سری قوانین هستند که مربوط به اون حوزه می شوند و به قوانین تجاری معروف هستند. خوب بهتر نیست این قوانین هم در لایه ای جداگانه قرار بگیره؟ پس این هم می تون لایه دیگه ای باشه.

نکته: گاهی جهت نظم دادن به کد یکسری متد تعریف می کنیم مثلا متدی که Serialize کردن رو به نحو خاصی که مد نظر ماست انجام بده. و این متد های به هم مرتبط رو در داخل کلاسی قرار می دهیم. دقت کنید که این کلاس لایه جدیدی نیست بلکه یک library و یا در حقیقت یک Helper‌ هست.

در پایان به این نکته اشاره کنم که تشخیص این لایه ها توسط فردی انجام می شه که سالها تجربه داره و طراح یا معمار نرم افزار هست. و شما باید در حد نیازتون این لایه ها رو ایجاد کنید و جایی که دلیلی نمی بینین و مفهوم اون لایه رو نمی دونید تحقیق کنید و بعد اون رو پیاده کنید. به فرض در لایه نمایش شما برای اینکه بطور کامل طراحی فرم رو از منطق اون جدا کنید می تونید از الگوهای MVC‌ و MVVM و ... استفاده کنید.

توصیه من اینکه بجای اینکه خیلی خودتون رو درگیر لایه ها کنید در درجه اول Design pattern ها رو مطالعه کنید.