در این مقاله به بررسی مزایای فریمورک SP-Based خواهیم پرداخت. مزایای شناسایی شده برای این فریمورک بالای 30 مورد است که در اینجا 10 مورد که برخی مشتمل بر چند ریز مزیت هستند را تشریح می کنیم. این مزایا در عمل باعث میشود که هزینه و زمان توسعه کاهش یافته و انعطاف پروژه در مقابل تغییرات افزایش یابد.
کدنویسی معمول باعث افزایش چشمگیر فایلها و پوشه های پروژه شده که مدیریت نسخه ها و تغییرات آن نیاز به نرم افزارهای Version Control مثل GIT دارد. در پروژه های بزرگ هزاران فایل و پوشه ایجاد میشود که بسیاری همنام هستند و توسط تیم توسعه مدام باید Push و Pop شوند، چالشهای اساسی در Conflict و merge به چشم میخورد. راه اندازی پروژه با کلی فایل حتی branch شده به صورت لوکال توسط تک تک افراد تیم حتی یک آزمونگر ساده هزینه توسعه را افزایش میدهد. طبق اصل زیر این کار اصولی نیست.
فریمورک SP-Based برای حل چالش فایل محوری راهکار کدنویسی مجازی مبتنی بر SP را ارائه داده است. SPها در این فریمورک حداقل خطوط پیاده سازی عملیات CRUD را دارند. ساده و کم حجم هستند و اثر جانبی روی قطعه کدهای دیگر ندارند بنابراین اغلب نیاز به VC ندارند. در وب سرور و کلاینت از تکرار کدهای فرمالیته برای نگاشت درخواست به SPجلوگیری شده است. با گسترش ابعاد پروژه لایه میانی رشد چندانی نداشته و مدیریت آن ساده است.
اصل KISS میگوید اینقدر باید کدنویسی را ساده انجام کرد که همه فهم باشد. این فریمورک بخاطر جدا کردن منطق کسب و کار به بخشهای کوچک و قابل مدیریت با حداقل کدنویسی توانسته در عین حال سادگی کدها را نیز حفظ کند. کدهای موجود در SPها برای اکثر عملیاتها به 5 خط هم نمیرسند. کدهای موجود در لایه میانی و کلاینت هم یک خط مشی یکسان را برای همه درخواستها دنبال میکنند که بررسی و توسعه آن ساده می باشد.
از آنجا که فریمورک SP-Based دارای کدهای پایه ای اندک در لایه های کلاینت و سرور است بنابراین می تواند در زبانهای مختلف چون c#، php، جاوا و ... پیاده سازی شود. با بانک اطلاعاتی اوراکل، Sql Server و همه DBهای رابطه ای که SP را پشتیبانی میکنند کار کند. انواع کلاینتها هم می توانند از این فریمورک به خوبی استفاده کنند.
کلاینتهای متعددی از انواع مختلف از مرورگرها، Appهای موبایل، دیوایسها و حتی سامانه های همکاری میتوانند به مجموعه ای از هندلرها تحت این فریمورک متصل شوند. این هندلرها میتوانند با زبانها و پلتفرمهای مختلف پیاده سازی شده باشند. هر HTTP هندلری سروری هم می تواند مستقلا به تعداد نامحدودی منبع داده ای متصل شود.
فرازبانی بودن این فریمورک میتواند اتحاد مبارکی بین توسعه دهندگان با زبانها مختلف در سطح سازمان، هلدینگ یا سازمانهای مختلف با هم ایجاد کند. مجموعه بزرگی از توسعه دهندگان می توانند برنامه هایی را توسعه دهند که از فریمورک SP-Based قدرت گرفته باشند، در این صورت سهولت بالایی در استفاده اشتراکی و کنترل شده از عملیاتهای موجود در هر برنامه قابل انجام است. بدون اینکه توسعه دهندگان نیاز باشد کار خاصی انجام دهند تنها با تعیین سطح دسترسی میتوانند همانند خود برنامه میزبان از دیتاها و کدهای موجود در آن به صورت منعطف و کنترل شده استفاده نمایند. از طرف دیگر صرفه جویی زیادی در کاهش هزینه تهیه سرورها برای ذخیره و پردازش داده ها صورت خواهد گرفت. حداقل داده ها در سرورهای هر بخش ذخیره خواهد شد. میتوان سرورهای مرکزی برای ثبت داده های پایه داشت.
از آنجا که تمام درخواستها از یک کانال واحد در سرور عبور میکنند پیاده سازی انواع سیاستهای امنیتی و کنترل سطح دسترسی خیلی ساده صورت میگیرد. هر کاربری که در برنامه لاگین میکند کدی دریافت میکند که در جدولی شناسه عملیاتهایی که میتواند اجرا کند مشخص شده است، بنابراین احراز هویت برای اجرای عملیاتها توسط چند خط کد محدود با یک کوئری ساده صورت میگیرد.
رولها نیز مجموعه ای از دسترسی های اجرای عملیاتها میباشند. که براحتی به هر کاربر قابل تخصیص است. دسترسیهای تعریف شده برای هر کاربر به ازای هر عملیات قابلیت انعطاف بالایی دارد پارامترهای مختلفی چون تاریخ شروع و انقضا، IP مجاز اجرا و یا حتی دفعات اجرا در آن قابل تعریف است. این پارامترها مخصوصا برای برنامه های تجاری که عملیاتها و دسترسی های زیادی دارند اهمیت بیشتری دارد. چون براحتی میتوانند انواع سیاستهای کنترلی را اعمال کنند. به عنوان مثال مانند مصرف انرژی قبض صادر کنند و محدوه مجاز را تعریف کنند و امکان محاسبه تصاعدی اجرای هر عملیات را هم در نظر بگیرند.
یکی پر چالشترین کارهای توسعه نرم بخاطر تکراری و سطح پایین بودن آن، اعتبارسنجی مقادیری ورودی فرمها میباشد. کنترل ورودی در کلاینت و نمایش پیغام مناسب و فوکوس دادن کاربر روی المان یا بخش مرتبط و سرور هم چون نمیتوان به اعتبارسنجی کلاینتی اکتفا کرد بایستی اعتبارسنجی تکرار شود که اکثرا نیاز به تخصص فنی بالایی ندارند.
اعتبارسنجی در فریمورک SP-Based به شکل جالبی هندل میشود. در سمت کلاینت با توجه به کلاس المانهای ورودی به صورت خودکار اعتبارسنجی، نمایش پیغام و فوکوس دادن انجام میشود. در سمت سرور نیز اعتبارسنجی مقادیر دریافتی به صورت خودکار با توجه به نوع پارامتر ورودی SP مجری درخواست بدون نیاز به نوشتن کد اختصاصی صورت می گیرد. این عدم استفاده از نوع داده ای مربوط به لایه میانی باعث سهولت و دقت بیشتری در اعتبارسنجی ورودی شده است. مثلا برای تعیین فیلد رشته ای به طور کلی در زبانهای لایه میانی نوع داده ای String در نظر گرفته شده است. در صورتی که در بانک اطلاعاتی طول رشته هم اهمیت دارد. اعتبارسنجی پویا هم از دیگر مزایای این معماری است در فصول بعدی نحوه پیاده سازی آن شرح داده شده است.
یکی از چالشهای بزرگ بسیاری از برنامه ها قابلیت پیاده سازی تراکنشهای پیچده و Long Lived است. این تراکنشها از کوئریهای سنگین و یا کوئریهایی که چندین جدول DB را به مدت طولانی قفل میکنند تشکیل شده است. پیاده سازی این تراکنشها به طور معمول باعث تولید کدهای زیادی میشود که شکستن آنها به قطعه کدهای کوچکتر کار دشواری است.
فریمورک SP-Based چون مبتنی بر SQL کار می کند محدودیتی در پیاده سازی انواع کوئریهای پیچیده ندارد، همچنین با توجه به دسترسی به پارامترهای درونی DB میتواند بهتر کوئریهای Long Lived را هندل کند. یکی از مزایای مهم فریمورک SP-Based امکان به تعویق انداختن درخواست وارده میباشد. بسیاری از فریمورکها در شرایطی که هنوز تراکنش Long Lived قبلی به پایان نرسیده تراکنش جدید وارد شود آن را بی پاسخ می گذارند. تعویق به این معنا که تراکنش را با کدخاصی به کلاینت پس داده و موتور تعاملی فریمورک با دیدن این کد میتواند کاربر را مطلع کرده و یا به صورت خودکار بعد از مدتی درخواست را دوباره ارسال کند.
در زیر نمونه ای کوئریهای پیچیده که توسط ORMها بخوبی قابل پیاده سازی نیست اما فریمورک SP-Based میتوانید آنها را بخوبی پیاده سازی کند را میتوانید مشاهده کنید.
- کوئریهای تو در تو شامل زیر کوئرهای مختلف در قسمتهای where و from میباشند. برای این منظور مجبورند این کوئری های را بشکند در نتیجه حجم و پیچیدگی کد افزایش پیدا میکند.
- کوئریهای پویا با کمک ساختار case end امکان پذیر نیست. این کوئریها در ORM با شروط مختلف و ساختارهای مختلف و کدنویسیهای مختلف انجام می شود. این کوئریها در فیلترینگها و گزارشگیریهای پیچیده کاربرد فراوانی دارند.
- جوینهای پیچیده در پروژه های بزرگ بسیار به کار میروند. گزارشهایی که مستلزم ارتباط جداول متعددی هستد که گاها تعداد آنها آنقدر زیاد میشود که ORMها هم مجبورند از SP استفاده کنند.
- پیاده سازی کوئریهایی که شامل توابع تجمعی، group by ، Order by، having و ... است در ORMها باید کلی توابع تو در تو برای دریافت خروجی مناسب نوشته شود.
به طور معمول رهگیری و کشف خطاهای زمان اجرای برنامه ها کار ساده ای نیست، هر چند بسیاری از فریمورکها مکانیزمهایی برای خودکار کردن آن ارائه داده اند، اما همچنان به صورت کامل و ساده امکان هندل کردن آن را ندارند. بنابراین توسعه دهندگان برای آنکه برنامه در نقطه ای از اجرا دچار توقف و نمایش خطای سیستمی نشود بایستی بوسیله ساختارهای try-catch اقدام به مدیریت خطاها کنند. لاگ کردن خطاها و ثبت جزئیات خطا هم از چالشهای دیگر رهگیری خطاهای سامانه است.
فریمورک SP-Based دارای یک HTTP هندلر واحد برای اجرای تمام درخواستهای کلاینت میباشد که اگر به خطا بخورد بسادگی با ساختار try-catch جزئیات خطا ثبت میشود. این کار از دوباره کاری و تکرار متعدد کدهای هندل کننده خطا و ثبت لاگ جلوگیری میکند. این مکانیزم باعث محدود شدن بروز خطا، رفع آسان آنها و عدم درگیری با خطاهای پیچیده و گسترده ORMها میشود. همچنین امکان اعمال انواع سیاستهای رهگیری و حل خطا مثل اطلاع رسانی سریع و تعریف تسک برای آنها فراهم میشود.
افزون بر این به علت ماهیت ایزوله بودن کدها در SPها خطاهای رخ داده خیلی سریع شناسایی و رفع میشوند و بدون نیاز به کامپایل مجدد برنامه، امکان خدمت رسانی خواهد داشت. بنابراین زمان downtime سامانه خیلی پایین است. اشکال اساسی مطرح ضعف در تریس SP است که بخاطر محدود بودن خطوط اکثر SPها (کمتر از 5 خط) این مشکل چندان جدی نیست.
خطاهای احمقانه ای که فریمورک میگیرد
درخواستهای HTTP با متدهای مختلفی می توانند به وب سرور ارسال شوند. متدهای Post، Get، Put، Patch و Delete برای اجرای عملیاتهای CRUD در وب سرور مرسوم هستند. اما فریمورک SP-Based استاندارد FCRDE (شرح در فصل 5) را برای دسته بندی عملیاتها تعریف کرده است که علاوه بر CRUD ایجاد فرم جدید و ویرایش ماژولها را هم شامل میشود. هندلر HTTP موجود در وب سرور برای هندل کردن عملیاتهای FCRDE مربوط به ماژول به متد HTTP درخواست توجه میکند. همان متدهای 5 گانه به عملیات 5 گانه FCRDE ماژول نگاشت میشوند.
از مشخصات یک REST API خوب آن است که متدهای HTTP متناسب با نوع درخواست استفاده میکند. بدین ترتیب هندل کردن آن درخواست در کلاینت و سرور امنتر، راحتر و سریعتر خواهد شد. این کار به طور معمول باعث پیچده گی و افزایش کدنویسی میشود. اما در این فریمورک ارسال درخواست HTTP با متد مناسب بصورت خودکار صورت میگیرد. برای این منظور برای انواع المانهایی که باعث اجرای عملیاتهای FCRDE میشوند کلاسهای CSS خاصی در نظر گرفته میشود. به عنوان مثال برای ذخیره سازی فرمها متد Post و و کلاس Save، ویرایش رکورد متد Get و کلاس Edit که قالبا روی TD جداول با آیکون خاصی نمایش داده میشود و برای دکمه حذف متد Delete با کلاس Delete که به شکل ضربدر قرمز یا هر آیکونی نمایش داده میشود.
یکی از مهمترین تسهیلات این فریمورک ثابت بودن آدرس HTTP هندلر است. بنابراین درخواستها برای دریافت پاسخ تنها با یک آدرس تعامل دارند. درخواستها برای اجرا باید دو پارامتر متد HTTP و شناسه ماژول را همراه داشته باشند. متد از روی کلاس المان کلیک شده و شناسه ماژول هم از روی متغیرهای داخلی مرورگر تعیین میشود. زمانی که فرم جدید یا ویرایش مربوط به یک ماژول فراخوانی میشود شناسه ماژول جدید ثبت میشود.
تسلط به کدهای هسته مرکزی این فریمورک بخاطر ساختار ساده و مشخصی که دارد، براحتی قابل انجام است. متدها، متغیرها، کلاسها و آیتمهای خیلی کمی وجود دارد. اصل برنامه یعنی اجرای درخواستهای کلاینت، بصورت خودکار از روی نام ماژول و متد HTTP به SP مربوطه نگاشت میشود. بخاطر ساختار دسته بندی عملیاتهای ماژولها توسعه دهنده سریع می تواند عملیاتهای پیاده سازی شده هر ماژول را تشخیص دهد و عملیاتهایی که هنوز پیاده سازی نشده است را کامل کند.
از آنجا که زبان SQL ترفندهای جالبی برای پیاده سازی شرطها و حلقه ها دارد. در نتیجه برای تولید گزارشات و فیلترینگهای مربوطه نیاز به کدنویسی کمتری میباشد. در حالت معمول نیاز است که ساختارهای حلقه ای و شرطی متعددی در لایه میانی برای ساخت انواع گزارشات و اعمال فیلترینگ روی آنها انجام شود.
یکی از معیارهای اصلی در کاهش هزینه نیروی انسانی، پشتیبانی و توسعه، سهولت و سادگی در کدها میباشد. هر چه کدها کمتر باشد مدیریت آن ساده تر است در نتیجه سریعتر برنامه توسعه یافته و نیروی متخصص با سطح سواد پایینتری نیاز دارد.
در معماری MVC هر ماژول ویوهای مستقلی دارد که باعث تولید فایلهای متعدد CSS، JS و HTML میشود. پیاده سازی معماری تک صفحه ای هم باعث افزایش چشمگیر پیچیدگی شده و اصولی نیست. بنابراین هر ماژولی باید به صورت مستقل کدهای کلاینتی و سروری ایجاد کند. در صورتی که بسیاری از روالها مثل اعتبارسنجی، تعامل با سرور و پردازش درخواست روال عام و یکنواختی دارند.
فریمورک SP-Based برای پیاده سازی ماژولها و عملیاتهای برنامه به صورت تک صفحه ای اقدام میکند. یعنی برنامه تنها یک ویو دارد. فایل ویو فقط شامل چهارچوب اصلی قرارگیری هر بخش است. با شروع اجرای عملیاتها محتوای متناسب مثل نوار منو، داشبورد و ... در آن به صورت پویا توسط SP پر میشود. در ادامه بعد از انتخاب هر گزینه در نوار منو یا داشبورد به صورت پویا محتوای HTML عملیات درخواستی در کانتینر (مفهوم کانتینر در فصل 5 بررسی میشود) قرار داده میشود.
هندل کردن تعامل با سرور بسته به متد عملیات درخواستی از یک درگاه و کانال عبور میکند. بدین ترتیب با کدهای محدود جاوا اسکریپتی میتوان انواع سیاستهای تعاملی با سرور را در جهت حداکثر کردن اعتبارداده ها، ارائه بهترین تجربه کاربری، انتخاب فرمتهای مناسب ارائه داده، رندر کردن صحیح و منعطف خروجی و .... اعمال کرد. این سبک کدنویسی امکان پاسخگویی به حجم بالایی از درخواستها را با درگیری حداقلی سرور ایجاد میکند.
برنامه نویسی OO و ORM حساسیت زیادی روی تعریف دقیق مدلها، فیلدها، مقداردهی، ارث بری و ... دارد و چالشهایی هم مثل بروز اثر جانبی دارد. بدین ترتیب برای کنترل ورودی کلاینت، پردازش درخواست و ارسال خروجی مناسب هزینه پردازشی و کدنویسی بالایی را تحمیل میکند. به عنوان مثال لازمه اجرای یک عملیات ساده مثل insert مقداردهی تک تک فیلدهای و اجرای متدهای متعدد برای دریافت شناسه رکورد درج شده میباشد. در صورتی که با دو خط کدنویسی SQL این کار شدنی است.
فریمورک SP-Based از یک مکانیزم خاص به نام Lookup برای اجرای درخواستها استفاده میکند. اما به جای اینکه درخواست را به یک شی نگاشت کند آن را به یک SP نگاشت میکند. ایجاد این روال دارای دو مزیت زیر را به نسبت روال معمول دارد.
- تعیین SP و DB مربوطه از روی ماژول و متد دریافتی به صورت خودکار و با چند خط کد محدود انجام میشود. جدول Lookup جزئیات کامل SP را ارائه میدهد. در مدل شی گرایی بعد از Lookup یک شی ارائه میشود که باید به صورت دستی متد مجری درخواست تعریف و مقداردهی شود، همچنین ایجاد کانشن پویا به DBهای مختلف نیز اکثرا نشدنی است.
- پارامترهای ورودی SP با کمک یک حلقه به صورت خودکار تعریف و مقداردهی میشوند. اما در مدلهای شی گرایی باید دقیق فیلدهای مدل به همراه نوع داده ای تعریف شوند. مقداردهی آنها نیز مستلزم ایجاد یک شی از آن مدل و مقداردهی و انتساب دستی تک تک فیلدها میباشد.
دسته بندی عملیاتهای مشابه ماژولها و تجمیع آنها از دیگر موارد افزایش توسعه پذیری این فریمورک است. مثلا ایجاد فرم جدید و ویرایش چون خروجی تقریبا یکسانی دارند و همچنین درج و بروزرسانی رکورد چون پارامترهای ورودی یکسانی دارند تجمیع شده اند. از طرف دیگر خروجی تمام SPها رشته ای است و در نتیجه هندل کردن پردازش آنها در سرور و کلاینت راحتتر است. بخاطر کدنویسی در SP از امکانات DBMS حداکثر استفاده را برده و با توسعه این کارکردها میتواند از امکانات جدید آن با حداقل هزینه بهره مند شود.
این فریمورک بخاطر رویکردی که در پیاده سازی منطق کسب و کار دارد، امکان پیاده سازی پروژه ها را با انواع مدلهای توسعه چابک دارد. در نتیجه امکان شروع پیاده سازی سریع پروژه با کمترین تحلیل را داشته و هزینه تغییرات در این فریمورک پایین است. بخش مهمی از مستند سازی مربوط به کدها به صورت خودکار تولید شده و مدیریت تسکها هم به صورت سیستمی انجام می شود.
تجمیع فریمورکها بالاخص در فریمورکهایی جاوایی مثل تجمیع هایبرنت و اسپرینگ جهت پیاده سازی برنامه کارآمدتر خیلی مرسوم است. فریمورک SP-Based یک فریمورک full stack است که میتواند با انواع فریمورکها تجمیع شود. این فریمورک شامل موتور پردازشگر رویدادها در کلاینت برای پوشش ویوی برنامه و HTTP هندلر برای اجرای مستقیم، سریع و ساده درخواستها با کمک SP در سرور میباشد. بدین ترتیب اگر تمام یا بخشی از برنامه با کمک SP راه اندازی شود این هندلر بخوبی میتواند جوابگوی اجرای آنها باشد.
موتور پردازشگر رویدادها در پیاده سازی ویوی داینامیک مورد استفاده قرار میگیرد. امکان مدیریت عملیات ماژولها تحت یک صفحه و هندل کردن خودکار انواع رویدادهای را با کمک jQuery فراهم کرده است. برای 4 دسته رویداد اصلی برای ماژولهای مختلف عملیاتهای زیر را به صورت خودکار انجام میدهد.
- نمایش فرم جدید و ویرایش: خواندن شناسه رکورد (صفر برای فرم جدید) و ارسال آن با شناسه ماژول با متد Get به سرور
- ذخیره سازی فرمها: خواندن مقدار المانها، اعتبارسنجی، تجمیع مقادیر و ارسال مقادیر و شناسه ماژول با متد Set به سرور
- حذف رکورد: خواندن شناسه رکورد، نمایش پیغام تایید و ارسال درخواست با متد Delete به سرور
- گزارشگیری: خواندن مقادیر ورودی مربوط به فیلتر، تجمیع مقادیر و ارسال آنها به همراه شناسه ماژول با متد Patch به سرور
توسعه دهندگان با توجه به شرایط مختلفی که دارند میتوانند از هندلر کلاینتی یا سروری در کنار فریمورک مدنظر خود استفاده کنند. اما کارآمدی این فریمورک در زمانی که هر دو سمت کلاینت و سرور با هندلرهای تعریف شده پیاده سازی شود خیلی بالاتر است و پشتیبانی هم راحتر خواهد بود.
