آی تی نرد

اشتراک اطلاعات و تجربیات در زمینه ی توسعه ی دات نت و البته شیرپوینت

روش ها و نگرانی های(Concerns) پیاده سازی در یک پروژه و ارائه راهکارها به طور خلاصه

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

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

از جمله ی این اصول میتوان به برخی موارد زیر اشاره کرد:

  • ساده گرفتن: عدم پیچیده کردن و سخت دیدن و نوشتن کد.
  • عدم تکرار: عدم تکرار مواردی که میتوان به صورت abstract تعریف کرد و در یک مکان مشترک برای استفاده قرار داد. در واقع می بایست برای هر قسمت از تحلیل سیستم فقط یک قطعه پیاده سازی که آن را حل و پیاده سازی می کند وجود داشته باشد.
  • بیشتر بگید و نپرسید: می بایست وظیفه ی هر کلاس و قطعه کد به صورت کامل تعریف شده باشد و به کلاس گفته شود و نتیجه گرفته شود تا اینکه از وضعیت یک آبجکت پرسیده شود و براساس این وضعیتها نتیجه ایجاد شود.
  • نیازی نخواهید داشت: عدم نوشتن کدهایی که ممکن هست فکر شود در آینده لازم شود و درواقع می بایست با نوشتن کدهای Test کارایی و عملکرد سیستم را ثابت کرد و سپس تنها قسمتی از کد که باعث pass شدن Test میشود نوشته شود.
  • جداسازی نگرانیها: فرایند تقسیم نگرانیهای پروژه به قسمتهای کوچکتر و تعیین وظیفه و نحوه ی رفتار هر قسمت باعث میشود تا استفاده ی مجدد از یک کد بیشتر و یافتن مشکل و رفع آن راحتتر و همچنین قابلیت تست پذیری بیشتری داشته باشد.
  • و برخی موارد دیگر...

معماری که میتوان این اصول را در آن راحت تر رعایت و پیاده سازی کرد معماری چند لایه(N-Tier Architecture) می باشد. شرح این معماری و نحوه ی پیاده سازی آن در زیر آمده است:

یکی از انواع معماری های چند لایه معماری سه لایه هست(3-Tier) که حداقل تعداد لایه ها می تواند باشد.

در این معماری Object های نرم افزار در سه لایه ی اصلی طراحی میشوند که البته خود هر لایه نیز میتواند به لایه های بیشتری تقسیم شود که بستگی به وسعت و پیچیدگی پروژه دارد(افزودن لایه ها به مفهموم بهتر بودن آن نمی باشد).

بخش ها یا لایه های اصلی نرم افزار در این معماری عبارتند از :

1 - Presentation Layer: یا همان لایه Interface نرم افزار ... فرمها, واسطها و منوها و هر چیزی که برای کاربر قابل رویت باشد, در نرم افزارهای تجاری و کاربردی همه ی این موارد در لایه نمایش یا Presentation قرار دارند. این لایه در ارتباط با کاربر هست و  حاوی عناصر User Interface (رابط گرافیکی کاربر) و شامل تمامی منطق حکم فرما در نحوه ی ارتباط کاربر با اجزای سایت  می باشد. لایه نمایش، بخشی از سایت است که کاربران می توانند آنرا مشاهده کنند و با استفاده از عناصر آن، از امکانات سایت استفاده کنند، بنابراین طراحی صحیح و اصولی این بخش تاثیر بسزایی در موفقیت وب سایت دارد. بدین منظور سعی میشود تا از کنترلها و کامپوننتهای معروف و مفید آماده که باعث سرعت در پیاده سازی و قابل درک بیشتر برای کاربر نهایی باشد استفاده شود که از مهمترین آنها میتوان از Telerik و DevExpress نام برد.

2 - BLL) Business Logic Layer): یا لایه تجاری که در بر گیرنده منطق اصلی برنامه هست.

در این لایه اعمال اصلی نرم افزار با استفاده از همکاری با لایه های پایین و بالا انجام میشه . در این لایه کار های مرتبط با Database وجود ندارد و این وظایف تماما به لایه Data Access سپرده میشود.

این لایه که معمولا لایه میانی (Middle Tier) نیز نامیده می شود وظیفه ارتباط بین لایه نمایش و لایه داده را بر عهده دارد.

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

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

3 - DAL) Data Access Layer): لایه دسترسی به داده ها  پایین ترین لایه در معماری سه لایه و البته مهمترین لایه در معماری سه لایه . لایه Data وظیفه مدیریت اطلاعات موجود در دیتابیس را بر عهده دارد و بر اساس دستوراتی که لایه Business به آن می دهد، اطلاعاتی را در دیتابیس اضافه، حذف، ویرایش و یا جستجو می کند و نتیجه این اعمال را به Business Tier باز می گرداند.

با پیاده سازی این معماری و با توجه به مجزا بودن بخش های مهم سیستم یا پروژه میتوان به راحتی آن را تغییر و یا توسعه و یا رفع مشکل کرد برای مثال با کمترین تغییر میتوان قسمت Presentation آن را از وب به ویندوز تبدیل کرد بدون اینکه نیازی به تغییر لایه های دیگر وجود داشته باشد و یا دیتابیس آن را از Sql Server به Oracle تغییر داد.

در این لایه می بایست نوع اینترکت با داده در دیتابیس نیز انتخاب شود برای مثال می توان از Entity Framework یا NHirbernate استفاده کرد.

Logging و ثبت خطاها و رویدادهای مهم:
یکی از مواردی که می بایست در تمام پروژه ها رعایت و پیاده سازی شود که البته در پروژه های بزرگ حیاتی می باشد لاگ رویداد ها و خطاهایی است که در پروژه و کد اتفاق می افتد. بدین رو ابزارهای خوب و رایگانی مانند elmah میتواند استفاده شود. هرچند که می بایست موارد امنیتی برای استفاده از آن رعایت شود. در صورتی که پروژه در محیط شرپوینت استفاده شود از ULS Log خود شرپوینت نیز می توان اسنتفاده نمود. بنابراین در صورت امکان اگر این قسمت به گونه ای پیاده سازی شود که امکان سوویچ داشته باشد بهتر می باشد.

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

الگوها به شرح زیر میباشد:

این 23 الگو طبق دسته بندی فرض شده توسط آنها (که هنوز هم رعایت میشود) در 3 گروه زیر جای گرفتند:

Creational patterns:
Abstract factory
Factory method
Builder
Prototype
Singleton

Structural patterns:
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Behavioral patterns:
Chain of responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template method
Visitor

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

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

خلاصه:

در این مطلب کلیدواژه های موثری ارائه شده است که میتواند Jump start ی مفید شود. و با در نظر گرفتن تمامی موارد ذکر شده میتوان پروژه ای با قابلیت فهم راحت تر، سرعت پیاده سازی بیشتر، قابل تست بودن، رفع اشکال راحت تر، قابل تغییر بودن با اعمال کمترین تغییرات و در نهایت توسعه پذیر تر تولید نمود.

Loading