رسانه فردا

یکی از مشهورترین تکنیک های یادگیری که در حال حاضر به صورت گسترده ای مورد استفاده قرار می گیرد، تکنیک لایتنر است که توسط محقق اتریشی ” سباستین لایتنر” طراحی شده است. هدف، انتقال مطالب از حافظه کوتاه مدت به حافظه بلند مدت است که شما را از تکرار بیش از حد مطالب بی نیاز می کند.

مدت ها پیش، در دوره فراموش نشدنی خدمت سربازی، یکی از دوستان(مهندس بابک شریف) ارائه ای با این موضوع داشتند، که مناسب دیدم فایل ارائه ایشان را در اختیار دوستان قرار دهم.

و برای کامل کردن مطلب به معرفی نرم افزاری با این کاربرد می پردازم:

Pauker، نرم افزاری Open Source به زبان جاواست که شما را از ساختن جعبه لایتنر و مصرف کاغذ بی نیاز می کند. از ویژگی های منحصر به فرد این نرم افزار، ارائه آن در نسخه های گوشی موبایل(با نام Mini Pauker) و کامپیوتر شخصی است.

Mini Pauker

Pauker

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

اطلاعات در این نرم افزار بر پایه XML، ذخیره می شوند که از نظر ما نرم افزاری ها ارزش بسیار زیادی دارد.

Dependency Injection

مبحث خلق اشیاء در طراحی نرم افزار همواره یکی از چالش های مطرح در بین اندیشمندان نرم افزار بوده که منجر به ابداع الگوهایی نظیر Dependency Injection یا همان DI شده است. DI الگو و تکنیکی است که باعث کاهش Coupling در کامپوننت ها می شود. DI معمولاً در کنار (و گاهاً به جای) اصطلاح Inversion of Control یا همان IOC به کار می رود. چکیده مفهوم DI در اصل هالیوود(Hollywood Principle) نهفته است:

Don’t call us, we’ll call you.

به کد زیر توجه کنید:

   ۱:      public class Invoice

   2:      {

   3:          private ILogger logger;

   4:          public Invoice()

   5:          {

   6:              logger = new TextLogger();

   7:          }

   8:          public void Submit(InvoiceDTO invoiceDTO)

   9:          {

  10:              // TODO: کد مربوط به ثبت فاکتور

  ۱۱:              logger.Log("Invoice submitted:" + invoiceDTO.Number.ToString());

  12:          }

  13:      }

در مثال فوق کلاس TextLogger یک Concrete از اینترفیس ILogger است که در کلاس Invoice جهت Log برداری از عملیات ثبت فاکتور به کار رفته است. مشخص کردن و نمونه سازی کلاس پیاده ساز ILogger یعنی کلاس TextLogger، در کلاس Invoice یک نمونه از عدم رعایت اصل هالیوود است که منجر به افزایش Coupling در سیستم می شود.

چیزی که مهم است اینست که مسئولیت خلق کلاس سرویس دهنده بر عهده کلاس Client نیست و Client به صورت کاملاً کور با اینترفیسی از کلاس سرویس دهنده کار می کند و در الگوی DI کلاس Concrete سرویس، توسط DI Container ها خلق و در کلاس Client تزریق(Inject) می شود. این کار (Injection) به روش های مختلفی از قبیل Constructor Injection، Setter Injection و Interface Injection انجام می شود.

Service Locator

الگوی دیگری که در حل این تیپ از مشکلات یاریمان می کند، الگوی Service Locator است. معمولا در این الگو یک Dictionary از اشیاء وجود دارد و بر اساس درخواست استفاده کننده شی مورد نظر باز گردانده می شود. تفاوت عمده ای که در DI و Service Locator وجود دارد اینست که Service Locator بر اساس درخواست(Request) کلاس Client، کلاس Concrete مورد نظر را می سازد و به Client باز می گرداند و این خود باعث ایجاد Dependency بین کلاس Client و Service Locator می شود.اما DI بر اساس درخواست کار نمی کند و کلاس Concrete را به کلاس Client تزریق می شود.

Dependency Injection Container

همان طوری که گفته شد، DI Container ها، مولفه هایی هستند که مسئولیت تخصیص(تزریق) Dependency ها را به دریافت کنندگان آن دارند. DI Container ها، عموماً با استفاده از الگوی Factory، مسئولیت خلق کلاس های Client و مولفه های مرتبط با آنها را بر عهده دارند. حداقل فایده هایی که از این کار بدست می آید عبارتند از:

• آسانتر و ایزوله تر شدن تست
• ارتقا دادن ارتباط سست(Loose Coupling) بین کلاس ها و زیرسیستم ها
• اضافه کردن قابلیت انعطاف در برابر تغییرات آینده
• بالا بردن قابلیت استفاده مجدد از کد

اهمیت موضوع باعث شده است تا DI Container ها، به یکی از الزامات Framework هایی نظیر SPRING .NET تبدیل شوند.

Martin Fowler در مقاله Inversion of Control Containers and the Dependency Injection pattern ، به طور کامل به این موضوع پرداخته است که توصیه می کنم حتماً مطالعه کنید.

Unity Application Block

Unity یکی از این  IOC Container هاست که توسط تیم Microsoft Patterns & Practices توسعه داده شده است و از انواع مختلف Injection از قبیل Constructor، Property و Method Call پشتیبانی می کند.Unity بر اساس فریم ورکی به نام Object Builder V2 بنا نهاده شده است. این نسخه از Object Builder متفاوت از نسخه ای است که در Enterprise Library ، نسخه ۳/۱ و قبل از آن استفاده شده است.امکاناتی که در Unity Application Block می توان نام برد عبارتند از:

• ویژگی اصلی هر IOC Container از جمله Unity اینست که مکانیسمی را برای ساختن(Assemble کردن)اشیایی که ممکن است دارای اشیاء وابسته(Dependent) ای باشند، فراهم می کند. در یک جمله Unity، خالق اشیاء و وابستگان آنست.
• یکی از ویژگی های منحصر به فرد Unity پشتیبانی از ویژگی سلسله مراتبی(Hierarchy) برای Containerها ست (Container های تو در تو). هر Container می تواند دارای تعدادی Container فرزند باشد. این ویژگی امکان Override کردن Dependency ها را به Container های فرزند می دهد.
• امکان Config کردن Container با استفاده از ساختارهای استاندارد XML.
• با استفاده از متد RegisterType می توان از Unity به عنوان یک Service Locator نیز استفاده کرد.
• پشتیبانی از Constructor، Property و Method Call Injection
• امکان Inject کردن Dependency ها به عنوان Singleton

در قسمت اول، کلیاتی از الگوی MVP گفته شد. گفته شد که در الگوی MVP با تفکیک شدن کد Business از UI قابلیت تست به خوبی پوشش داده می شود. در این قسمت سعی می کنم جزییات بیشتری از این الگوی UI را شرح دهم.

در یک برنامه کاربردی در یک صفحه یا فرم، اطلاعات Domain در قالب کنترل هایی به کاربر نشان داده می شوند.کاربر می تواند اطلاعات را تغییر دهد و نتیجه را مشاهده کند. کد زدن این تعاملات در Code Behind صفحات(فرمها) و نداشتن یک استراتژی مناسب باعث بروز مشکلاتی از قبیل پیچیدگی، دشواری نگهداری و دشواری در تست می شود.مشکل بزرگتر استفاده مجدد از این کدها در صفحه(فرم) دیگری است که به همان رفتارها نیاز دارد.

انتظار می رود الگوهای UI این مشکلات را برای ما حل کنند به این شکل که حجم بیشتری از کد را بتوان به شکل مکانیزه تست کرد، کدها را بتوان در بین صفحات(فرمها) به اشتراک گذاشت و نهایتاً بتوان UI Logic را به صورت کاملاً مشخص از Business Logic جدا کرد تا خوانایی و قابلیت نگهداری آن بالا برود.

در MVP دو مسئولیت نمایش بصری اطلاعات و هندل کردن رویدادها در دو کلاس View و Presenter تفکیک شده اند.View کنترل های صفحه را مدیریت می کند و رویدادها را به Presenter منتقل می کند.Presenter که شامل UI Logic است، نسبت به رودادها واکنش نشان می دهد و وضعیت View را اداره می کند.نکته مهم این که Presenter به اینترفیسی از View دسترسی دارد و از کلاس Concrete ی View هیچ اطلاعی ندارد و این اصل، قابلیت تست را در این الگو بالا می برد.

شکل زیر به خوبی مفهوم MVP را می رساند:

MVP دارای سه جزء اصلی به شرح زیر است:

1. Model: مدل آبجکت سطح Domain است که دیتای Application را نگه می دارد و متدهایی را برای دسترسی به این دیتا فراهم می کند.یک مدل نباید هیچ ارتباطی با User Interface داشته باشد.این محدودیت این امکان را فراهم می کند که در شرایطی که لازم باشد UI به طور کلی عوض شود، کدها به راحتی قابل استفاده مجدد باشند. در واقع Model هیچ دانشی از وجود View و Presenter ندارد.
2. View: پنجره ای است شامل مجموعه ای از کنترل های UI، که وظیفه اش نمایش/گرفتن اطلاعات مدل به/از کاربر است.این کار با ارتباط غیر مستقیم View و Model انجام می شود، که در این ارتباط غیر مستقیم، View یک Observer بر روی Model است. بسته به قالب UI، این پنجره می تواند User Control، WindowsForm، WebForm و یا هر چیز دیگری باشد.
3. Presenter: همانطوری که گفته شدView وظیفه دارد تا خروجی اطلاعات Model را به کاربر نشان دهد یا اطلاعات ورودی کاربر را بگیرد. وظیفه Presenter نیز که به عنوان قطعه سوم این پازل سه تایی است، آماده سازی و به عمل آوردن اطلاعات مدل است.رفتار کاربر(از قبیل کلیک کردن، تایپ کردن و …) نیز که توسط View گرفته می شود به Presenter تحویل داده می شود. با این تعاریف Presenter اجازه دارد در مورد هر دوی Model و View بداند تا بتواند نقش واسطه و میانجی گری را بین این دو برقرار کند.

نحوه برقراری ارتباط بین Model و View، شاید دغدغه ای بوده که باعث شده است  الگوی MVP به دو شکل Passive View و Supervising Controller پیاده سازی شود.شکل زیر به خوبی بیانگر این تفاوت هاست:

Passive View دارای محدودیت بیشتری است، در مقابل Supervising Controller انعطاف پذیری بیشتری در UI های پیچیده دارد.باید به این نکته توجه کرد که این انعطاف پذیری در قبال از دست دادن بخش کمی از قابلیت تست بدست می آید.با این توضیحات، برای سیستم های که دارای UI پیچیده و متشکل از تعداد زیادی Grid است، الگوی Supervising Controller پیشنهاد می شود، در غیر این صورت Passive View انتخاب بسیار مناسبی است.

برای کسانی که با الگوی MVC کار کرده و آشنایی دارند، شاید این مطلب جالب باشد که MVP بر اساس و پایه MVC بنا شده است با این تفاوت که در آن کنترل کمتری روی View و Responsibility بیشتری روی Presenter است.می گویند که MVP فرزند و خلف MVC است.

وقتی در برنامه های کاربردی صحبت از امنیت می شود، موضوع صحبت، بخشی از نیازهای کارکردی(Functional) و بخشی دیگر از نیازهای غیر کارکردی است که شامل دو مقوله مهم Authentication و Authorization است.

{ Security } = { Authentication } + { Authorization }

Authentication مشخص می کند که شمای کاربر چه کسی هستید؟ و Authorization که همیشه بعد از Authentication و در صورت تأیید هویت کاربر انجام می شود، مشخص می کند که شما اجازه انجام چه کاری را دارید و اجازه انجام چه کاری را ندارید.

موضوع بحث ما مقوله دوم یعنی Authorization است و هدف معرفی سیستم های موجود، جهت الگوبرداری یا استفاده است.

Authorization Manager(AzMan)

Authorization Manager یا همان AzMan یک سیستم کنترل دسترسی Role-Base در محیط ویندوز است.

مدیریت این سیستم از طریق MMC یا همان Microsoft Management Console در محیط ویندوز انجام می شود.برای دسترسی به این ابزار(در صورتی که بر روی سیستم عامل نصب شده باشد) کافیست دستور azman.msc را در محیط Command Prompt اجرا کنید.

این ابزار امکان تعریف Operation و دسته بندی این Operation ها را در Task ها فراهم می کند.دسترسی نقش ها به این Operation ها و Task ها، تعریف و مدیریت کاربران و نقش ها و تخصیص کاربران به این نقش ها به راحتی در این ابزار قابل انجام است.

در AzMan می توان محل ذخیره سازی را بر حسب کاربرد در XML File یا Active Directory انتخاب کرد.

برقراری ارتباط در برنامه کاربردی به این سیستم به سادگی قابل انجام است.

اولین امکانی که در دات نت می توان به آن اشاره کرد، کلاس RoleManagerAzManProvider است.برای استفاده از این کلاس کافیست در تگ <roleManager> در Web.Config کلاس فوق را به عنوان defaultProvider مشخص کنیم.با این کار تمامی API مربوط به Roles از AzMan استفاده خواهند کرد.

برای چک کردن دسترسی ها در برنامه کاربردی که مهمترین دغدغه است بایستی از AzMan API که یک کتابخانه COM است استفاده کنیم.در این کتابخانه متدی با نام AccessCheck در اینترفیس IAzClientContext وجود دارد که دسترسی یا عدم دسترسی کاربر را به Task یا Operation خاصی را مشخص می کند.

نکته ی قابل ذکر این که در Enterprise Library در  Security Application Block روی Authorization هم کار شده که یکی از پیاده سازی های آن روی AzMan بوده است.توصیه من اینست که اگر قرار است از AzMan استفاده کنید، به جای این که مستقیماً از AzMan COM API استفاده کنید، از Security Application Block استفاده کنید.

.NET SQL Authorization Manager (NetSQLAzMan)

NetSQLAzMan پروژه ای است Open Source با مدلی شبیه به مدل AzMan با تفاوت ها و قابلیت هایی از قبیل:

- برخلاف AzMan(که COM است)، کتابخانه آن دات نت است.

- محل ذخیره سازی آن SQL Server است.

- برای Administration آن مانند AzMan می توان از کنسول MMC 3.0 استفاده کرد، اما علاوه بر این امکان، با کنسول وب بیس دیگری نیز که برای آن طراحی شده است، این کار قابل انجام است.

- در AzMan در Operationها، نمی توان Hierarchy داشت، اما در این ابزار چنین محدودیتی وجود ندارد.

- در AzMan دسترسی فقط دارای دو حالت است(Allow یا Deny) اما در این ابزار چهار حالت وجود دارد:اول) Allow with delegation دوم) Allow سوم) Deny چهارم) Neutral.

-  AzMan از اعمال Authorization در بازه زمانی خاص پشتیبانی نمی کند، اما در این ابزار چنین نیست.

- و خیلی قابلیت های دیگر …

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

بحث Access Control را قبل از این هم با پویا مطرح کرده بودیم، آخرین صحبتی که با هم داشتیم خاطرم هست که قصد داشت چنین سیستمی را طراحی کند ولی از نتیجه اش خبری ندارم.

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