از آخرین پستم مدت زیادی گذشته . اگر چه مطالب زیادی برای نوشتن داشتم اما واقعاً فرصت پیدا نمیشد . امروز یه مطلب برنامه نویسی براتون دارم . امیدوارم مفید باشه . من یه چند ماهی هست که در گیر استفاده کردن از Linq to Sql بجای Ado.net شدم .
استفاده از لینک هم مزایایی داره هم معایبی . اما مزیت اصلی که به نظر من استفاده از لینک داره (البته برای برنامه های کوچک) کاهش حجم کد نویسی هست  . با کمک لینک دیگه ما درگیر نوشتن خطوط زیاد برنامه برای اتصال به بانک اطلاعاتی و استخراج داده ها نمیشیم . ولی خود این مزیت هم باعث دردسرهایی میشه . یادگیری زبان لینک چیز ساده ای نیست . نوشتن پرس و جوهای پیچیده با لینک خودش یه دردسر بزرگه . از اون بدتر بازخوانی پرس و جوها هست . من خودم گاهاً نمیتونم خروجی پرس و جویی که قبلاً نوشتم رو حدس بزنم . برای نوشتن کوئری ها لینک چندتا ابزار  کمکی وجود  داره که من تقریباً همشون رو تست کردم . اما هیچ یک به قدرت ابزار Linqer نیستند . در آینده یه آموزش مفصل در یک پست جدا برای اون اختصاص میدم . ولی همین ابزار هم در کوئری ها پیچده دچار مشکل میشه و باید خود برنامه نویس اشکالات رو برطرف کنه .

اما موضوعی که امروز میخوام در مورد اون صحبت کنم بحث Multi tier architecture for Linq to Sql  در لینک هست . موضوعی که از اول استفاده من از لینک همیشه برام مورد سوال بود . اینکه با استفاده از لینک و نوشتن دستورات اون پشت فرمها تکلیف برنامه نویسی چند لایه چی میشه .اما خوشبختانه هر سوال اینترنتی جوابش هم توی اینترنت هست و فقط باید صبور بود و جستجو کرد . این پست  نتیجه تحقیقات بنده با اندکی تغییر در متن اصلی میباشد .

هدف این مقاله نمایش چگونگی پیاده سازی معماری چند لایه با استفاده از ابزار لینک و همچنین استفاده از ObjectDataSource بعنوان منبع داده ها در برنامه میباشد . ویژگیهای کلیدی  این روش توجه به خواسته های موجود  از  datacontext  و کلاس های موجود مخزن است که ارائه دهنده  راه کارهای ساده  پیاده سازی عملیات اضافه کردن ، ویرایش کردن و حذف کردن داده ها  (CRUD) با استفاده از  Generic DataType ها میباشد . اگر نیاز به اطلاعات بیشتر در مورد  نوع داده ای Generic هستید از این مقاله استفاده کنید . در اصل در این مقاله ما قصد ایجاد لایه Data Access یا همان DAL را با استفاده از تکنولوژی Linq داریم .

هر موجودیت بانک اطلاعاتی دارای یک کلاس مرتبط مخزن داده ای است  که وظیفه انجام عملیات های مختلف CRUD را بر عهده دارد .این کلاسهای مخزن داده های از کلاس GenericRepository  ارث بری میکنند که قبلاً در آن عملیاتهای مخلتف Select , Insert , Updateو Delete پیاده سازی شده است . در سورس زیر کلاس GenericRepository  نمایش داده شده است .

[System.ComponentModel.DataObject]
public class GenericRepository<TEntity, TDataContext>

 where TDataContext : DataContext
{
    public static List<TEntity> SelectAll()
    {
          ...
    }
    public static void Insert(TEntity entity)
    {
        ...
    }
    public static void Update(TEntity entity)
    {
        ...
    }
    public static void Delete(TEntity entity)
    {
        ...
    }
}

//ProductRepository class
public class ProductRepository : GenericRepository<
    Product, NorthwindDataContext>
{
}

در کد فوق کلاس Product و نام DataContext بعوان پارامترهای ورودی ارسال شده اند . توجه کنید این دو ورودی بصورت اتوماتیک توسط خود Visual Studio بصورت کاملاً ویزاردی تولید میشوند و شما کار اضافی انجام نمیدهید .

اما کلاس ما یعنی کلاس ProductStaticRepository با استفاده از یک الگو یا T4 Template  ایجاد میشود . این کلاس حاوی عملیاتهای استاندارد CRUD  است .

حال در زمان صدا زدن این کلاس در لایه های بالا تر کافیست خطوط زیر را وارد نماییم .

   
   var productRepository = new ProductRepository();
    products = productRepository.SelectAll();
   

                                                                                        
namespace DataLayer{
    public partial class ProductStaticRepository
    {
        
         
        public static IList GetByCategory(int id)
        {
            IQueryable res = SelectAll().Where(p => p.CategoryID == id);
            return res.ToList();
        }

        public static void InsertBlank()
        {
            Product p = new Product { CategoryID = 1,

            ProductName = "test", SupplierID = 1 };
            Insert(p);
        }
    }
}

                                                                                        
using System;

namespace DataLayer
{
    public partial class Product
    {
        partial void OnProductNameChanging(string value)
        {
            if (value == "")
                throw new Exception("Product name cannot be empty");
        }
        
    }
}

همانطور که قبلاً گفتم برای ایجاد کلاسهای مورد نیاز از یک الگو استفاده میکنیم . برای این کار نیاز به دو فایل DataClasses.tt و L2ST4.ttinclude داریم . روش کار بصورت زیر میباشد :

• ایجاد یک پروژه از نوع Class Library برای لایه داده ها





• ایجاد یک مخزن داده لینک (DataContext) به پروژه و تغییر نام آن به DataClasses.dbml . (باید نام این فایل با نام فایل الگو یکسان باشد ) . بعد از آن اضافه کردن جداول بانک اطلاعاتی مورد نظر به لینک .





• اضافه کردن دو فایل الگو به پروژه . در این لحظه باید پیام اخطار زیر بروی صفحه ظاهر شود  که مربوط به تولید خودکار کد توسط فایل الگو میباشد .
  با زدن دکمه OK فایل مورد نظر تولید میشود .

• در این مرحله باید کتابخانه GenericDataLayer به پروژه اضافه شود و فایل DataClasses.generated.cs که توسط MSLinqToSQLGenerator تولید شده  و در کنار فایل DataClasses.dbml.layout در زیر DataClasses.dbml حذف شود تا فایلی که توسط T4 Template ایجاد شده جانشین آن شود .  اکنون میتوانید پروژه را کامپایل نمایید .





ادامه مطالب در پست بعدی

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

هدف این مقاله نمایش چگونگی استفاده از واقعی از UML در فرآیند توسعه نرم افزار میباشد

محصول مورد نظر یک سیستم برای کنترل دستگاه آسانسوری است که در یک ساختمان با n طبقه نصب شده است . مشکل نگرانی های منطقی مورد نیاز برای حرکت بین دستگاه آسانسور طبقه با توجه به محدودیت های زیر می باشد :

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

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

• Use Case Diagram - نمودار مورد کاربری
• Class Diagram - نمودار کلاس
• Sequence Diagram - نمودار توالی
• Collabration Diagram - نمودار همکاری
• State Diagram - نمودار حالت

توصیف ویژگیهای نمودار

• توضیحات کلی در مورد اینکه چگونه از سیستم استفاده خواهد شد
• مروری بر عملکرد خواسته شده از سیستم فراهم می آورد
• قابل فهم شدن موضوع توسط یک شخص آماتور همانند یک شخص حرفه ای

نمودار مورد کاربری :

برای دیاگرام مورد کاربری بهتر است یک سناریو تهیه شود . در ایجاد سناریو باید به هر مرحله یک شماره اختصاص داده شود . با توجه به نمودار فوق می توان سناریو زیر را ایجاد کرد :

• رهگذر دکمه طبقه را فشار میدهد .
• سیستم آسانسور تشخیص میدهد که دکمه آسانسور فشار داده شده است .
• آسانسور به سمت طبقه ای که از آن درخواست رسیده حرکت می کند .
• پس از رسیدن به طبقه درب آسانسور باز می شود .
• رهگذر وارد آسانسور می شود و دکمه طبقه مورد نظرش را فشار می دهد .
• درب آسانسور بسته می شود .
• آسانسور به سمت طبقه خواسته شده به حرکت در می آید .
• آسانسور به طبقه مورد نظر میرسد و درب آسانسور باز میشود .
• رهگذر از آسانسور خارج میشود .
• درب آسانسور بسته میشود .

نمودار کلاس نمایش دهنده ساختار ایستای اشیاء بهمراه ساختار داخلی کلاس و روابط بین کلاسها میباشد .

نمودار کلاس :

نمودار حالت ترتیب حالتهای یک شی را در طول چرخه حیات شی در پاسخ به محرک ها بهمراه عملکرد و پاسخهای شی نمایش می دهد .

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

اگرچه نمودار توالی و نمودار همکاری هر دو یک بار معانی را دارند اما در دو شیوه مختلف مفهوم را بیان میکنند . نمودار توالی بصورت صریح ترتیب پیامها را بیان می کند و برای مدل سازی سیستم های بلادرنگ مناسب می باشد ، با این وجود نمودار همکاری ارتباط بین اشیاء را نمایش میدهد .

نمودار توالی :

نمودار توالی برای مدل سازی دکمه آسانسور

نمودار توالی برای مدل سازی دکمه طبقه

توصیف ویژگیهای نمودار

• مجموعه از فعل و انفعالات بین کلاسها و نوع ها را توصیف میکند
• روابط بین اشیاء را نمایش می دهد

نمودار همکاری

نمودار همکاری برای مدل سازی دکمه آسانسور

نمودار همکاری برای مدل سازی دکمه طبقه

5 . طراحی جزئیات
5.1 . جزئیات نمودار کلاس