فریمورک مبتنی بر استور پروسیجر(Stored Procedure Based)

1-استور پروسیجر

استور پروسیجرها قطعه کدهایی هستند که در بانکهای رابطه ای با زبان SQL جهت اجرای یک وظیفه خاص نوشته میشوند. بطور کلی، استور پروسیجرها نسبت به اسکیول خام در بیشتر جنبه ها برتری دارند. آنها سریعترند بخاطر Pre-Compiled بودن، امن ترند بخاطر جلوگیری از Sql injection، ترافیک کمتری ایجاد می کنند چون باعث باعث کمک شدن Round Trips بین وب سرور و بانک می شود
استفاده از SQL در لایه برنامه باعث در هم تنیده شدن آن با کدهای دیگر مثل پایتون یا C# می شود. اما کدنویسی در SP باعث تولید کدهای تمیز می شود. تقریبا تمام توسعه دهندگان براستفاده از استور پروسیجر در زمانی که کوئریهای سامانه طولانی و پیچیده است تاکید دارند. اما استفاده آن را به طور وسیع و گسترده صحیح نمی دانند چون باعث افزایش پیچیدگی در کدنویسی و افزایش یک لایه مضاعف در توسعه می شود.

2- انتقال منطق کسب و کار به SP

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

3- معرفی معماری و فریمورک SP-Based

معماری نرم افزار طرح، ساختار و نحوه تعامل بخشهای مختلف یک سامانه را مشخص می کند. انتخاب معماری متناسب با شرایط پروژه کمک شایانی در کاهش هزینه و افزایش سرعت اجرای آن دارد. تا حد امکان نباید به شخص، ابزار یا سخت افزار خاص وابسته باشد.  فریمورک SP-Based ترکیبی از معماری‌های مطرح است جدا بودن کدها در لایه های مختلف و رفع مشکل کدهای انبوه و تکراری، ایجاد صف برای دسته بندی عملیاتها و رفع مشکل کانالهای متعدد هندل رویدادها، هسته کوچک و رفع مشکل وابستگی اجزاء به هسته و امکان تعامل با انواع دیوایس ها از مزایای این فریمورک است. چالش اساسی برنامه نویسان حداقل کردن سورس کدها و پیچیدگی پروژه نیز تا حدود زیادی مرتفع شده است. فرآیند پاسخگویی به درخواستها به طور کلی در این فریمورک در 6 مرحله انجام می شود.
مرحله 1- بارگذاری: در این مرحله کدهای پایه ای جاوا اسکریپتی و HTML در مرورگر بارگذاری می‌شود.
مرحله 2–هندل  خودکار رویدادها: به خاطر قالب ساده رویدادها براحتی توسط  متد onدر jQuery، هندل می شوند. پردازش رویدادها براحتی با تامین دو پارامتر شناسه درخواست و مقادیر پارامترهای استورپروسیجر تعیین می‌شود. این دو پارامتر بوسیله خصوصیات موجود در المان و توابع جاوا اسکریپتی انجام می شود.
مرحله 3- ارسال درخواست: تعامل با سرور براحتی توسط متد post در jQuery صورت می‌گیرد و تابع callback آن برای پردازش مقدار برگشتی استفاده می شود.
مرحله 4- اعتبارسنجی: سرور برای پاسخگویی به تمام درخواستها از یک هندلر واحد استفاده می‌کند. هندلر شناسه درخواست کننده و IP را استخراج کرده و با کمک یک کوئری ساده سطح دسترسی کاربر برای اجرای درخواست را چک می‌کند.
مرحله 5- اجرای استور پروسیجر: بعد از اعتبارسنجی، با استفاده از شناسه درخواست، استور پروسیجر مجری تعیین و مقدار پارامترهای ورودی آن به صورت خودکار تعیین می‌شود. سپس استور پروسیجر اجرا شده و خروجی به کلاینت برگشت داده می‌شود.
مرحله 6- پردازش خروجی: تابع callback در مرورگر بعد از دریافت نتیجه اجرا می‌شود. به طور کلی نتیجه برگشتی شامل دو دسته است دسته اول ساده و عموما عددی است که عدم اجرای درخواست بخاطر عدم دسترسی یا بروز خطا و نتیجه اجرای موفق را مشخص می کند. دسته دوم شامل رشته است است که توسط توابع مرتبط با عملیات پردازش شده و نتیجه در مرورگر منعکس می‌شود. در شکلهای زیر می توان جزئیات مکانیزم این معماری را برای تعامل با کلاینتها مشاهده نمایید:

4- مزایای فریمورک SP-Based

1- حداقل کدنویسی: این فریمورک دارای کمترین کد خاص منظوره است، بنابراین در لایه Controller و View اکثرا کدهای ثابت نوشته شده برای هندل رویدادها و درخواستها کفایت می‌کند. با ایجاد یک کانال واحد برای اجرای درخواستها تمام مراحل را توسط یکسری توابع عام که چند خط بیشتر نیستند هندل می‌کند. این توابع طوری نوشته شده‌اند که برای اجرای درخواستهای نامحدودی پاسخگو باشند.
2- کدنویسی مجازی: کدنویسی مجازی مفهوم جدیدی است که بر ذخیره سازی سورس کدها در بانک بجای فایل تکیه داشته و کار تیمی را بسیار تسهیل می‌کند. تعیین دسترسی و نگهداری کدها آسان و کم هزینه بوده وامکان مدیریت کدها از طریقDevice های دیگر مثل گوشی و مرورگر را هم فراهم کرده است.
3- سازگاری بسیار بالا: سازگاری این فریمورک در ابعاد مختلف در تعامل با کلاینتهای با پلتفرمهای مختلف و زبانهای برنامه نویسی با بانکهای اطلاعاتی متفاوت بسیار بالا می‌باشد.. این امر بخاطر حجم پایین کدها و هسته کوچک است که امکان پیاده سازی آزادانه در کلاینتها، زبانها و بانکهای اطلاعاتی مختلف را فراهم کرده است.
4- سهولت و انعطاف در اعتبارسنجی: اعتبارسنجی‌ درخواستها برای اجرای استور پروسیجرها در این فریمورک توسط چند خط کد محدود با یک کوئری ساده صورت می‌گیرد. از آنجا که تمام درخواستها از یک کانال عبور می‌کنند پیاده سازی انواع سیاستهای امنیتی و کنترلی نیز خیلی ساده صورت می‌گیرد.
5- توسعه پذیری بالا: این فریمورک با دسته بندی و کپسوله کردن کدها درSP از بروز اثر جانبی در کدها جلوگیری کرده و بسیاری از عملیاتهای مشابه را با هم تجمیع نموده مثل ایجاد فرم جدید و ویرایش به خاطر خروجی مشترک و درج و بروزرسانی به خاطر ورودی مشترک. SP نیز دارای کدهای بسیار محدود و زود فهم است.
6- رهگیری اجرای درخواستها: بخاطر اجرای تمام درخواستها از یک نقطه با کمک یک دستور insert و یک ساختار try-catch جزئیات درخواست و در صورت بروز خطا متن خطای بروز کرده ثبت می‌شود. این کار از دوباره کاری و تکرار متعدد کدها جلوگیری می‌کند. با کمک این جزئیات مقدار دقیق پارامترهای اجرای استور پروسیجر جهت رهگیری تعیین می‌شود.
7- اتصال به منابع داده‌ای متعدد: با تعریف کانکشنهای متعدد این فریمورک می‌تواند براحتی درخواست رسیده از کلاینت را در بانکهای اطلاعاتی مختلف اجرا کند. انتخاب کانکشن نیز براساس شناسه درخواست یا یک پارامتر جداگانه قابل انجام است. در مدلهای ORM کار کردن روی Contextهای مختلفی کار بسیار دشواری است.
8- صرفه جویی در منابع سروری: این مزیت به خاطر اجرای مستقیم منطق کسب و کار در استور پروسیجر با حداقل کد میسر شده است. در وب سرور اجرای درخواست به چند خط محدود شده و بدین ترتیب حداقل استفاده از منابع پردازشی و حافظه صورت می گیرد. از طرفی بار پردازشی چندانی نیز به بانک اضافه نمی‌شود.
9- کاهش هزینه نیروی متخصص: اکثر کدهای نوشته شده در این فریمورک در SPبا زبان پایهSQL است، در نتیجه هزینه نگهداری و آموزش نیروی متخصص پایین است. از طرفی دیگر بهره وری نیرو بخاطر کمترین وابستگی عملکردی به دیگر نیروها بالا بوده و با افزودن نیرو می توان سرعت پروژه را افزایش داد.
10- سازگاری با مدلهای مدرن توسعه: این فریمورک امکان پیاده سازی پروژه ها با مدل های توسعه چابک و جزء به جزء را می‌دهد. این فریمورک به خاطر کپسوله کردن منطق کسب و کار در استور پروسیجر امکان شروع پیاده سازی سریع پروژه با کمترین تحلیل را می‌دهد و هزینه تغییرات در این فریمورک پایین است.
11- هندل کردن درخواست های انبوه: در این فریمورک بطور پیش فرض تمام درخواستها از کانالی واحد عبور می‌کنند که با افزایش بار می‌توان به صورت پویا تعداد آنها را افزایش داد. این قابلیت با رصد بار روی سرورها و میزان درخواستها به صورت خودکار یا دستی قابل انجام است. آدرس هندلر نیز در لود اولیه صفحه با توجه به بار روی سرورها تعیین می شود.
12- تعامل ساده کلاینت با سرور: به خاطر ثابت بودن آدرس هندلر در تمام درخواستها و فرمت تعامل ساده به صورت RESTبراحتی بسیاری از Deviceها می‌توانند با سرور تعامل داشته باشند. ثابت بودن آدرس هندلر این امکان را ایجاد می کند تمام درخواستها توسط یک قطعه کد به سرور ارسال شده و پاسخ دریافت شود.
13- اعتبارسنجی خودکار مقادیر: در سمت کلاینت و سرور اعتبارسنجی مقادیر دریافتی کاملا به صورت خودکار و بدون نیاز به نوشتن کد اختصاصی صورت می گیرد. این مزیت باعث شده انواع مختلف مقادیر براساس نوع المان و پارامتر سروری براحتی اعتبارسنجی شود. همچنین کنترل فیلدهای اجباری هم به این ترتیب خیلی ساده انجام می‌شود.
14- در دسترس بودن بالا: در سامانه های طراحی شده تحت این فریمورک به علت استفاده حداقلی از منابع سروری، سامانه در مقابل بار عملیاتی بالا کمتر دچار مشکل می‌شود. افزون بر این به علت مانیتورینگ دقیق خطاهای رخ داده به علت ماهیت کپسوله بودن کد در SP خیلی سریع رفع می‌شود و بدون کامپایل مجدد پروژه، سامانه وارد مدار می‌شود.
15- حداقل کردن ترافیک شبکه: اجرای منطق کسب و کار در این فریمورک در SP هندل می شود بنابراین کمترین میزان ترافیک بین وب سرور و بانک ایجاد می شود. نیاز به تعامل متعدد بین لایه کنترلر و بانک وجود نداشته و با اجرای یک SPاکثرا پاسخ موردنیاز کلاینت تامین می‌شود. ترافیک وب سرور و کلاینت نیز به خاطر ماهیت ساده خواندن مقادیر، شامل کمترین کارکتر اضافی می‌باشد.
16- عدم وابستگی به الفاظ: از آنجا که فریمورک براساس SP عمل می کند بنابراین برای رجوع به آنها از طریق یک شناسه عمل می شود که به نام SP نگاشت شده است. از طرف دیگر برنامه نویس اصلا نیاز نیست خود را درگیر حفظ و تایپ پارامترهای SP کند، چون به صورت خودکار تعریف مقدار دهی می‌شوند.
17- دسته بندی عملیاتها: تمام محتوای موردنیاز کلاینت در این فریمورک توسط SP از طریق 5 دسته عملیات،نمایش فرم جدید و ویرایش، درج و بروزرسانی، گزاشگیری، حذف و متفرقه تامین می‌شود، که به اختصار FCRDE (Form Create Report Delete Etc) گفته می‌شود. مزیت این دسته بندی دسترسی راحتر و سریعتر به سورس کدها و اعمال راحتر سیاستهای کنترلی می‌باشد.
18- تجمیع پویا: بسیاری از درخواستهای کلاینت از سرور شامل لیستی از فیلدها و رکوردهای بانک است. که این عملیات اکثرا از طریق حلقه‌های تکرار در لایه کنترلر پاسخ داده می‌شود. اما در این فریمورک با کمک دستور select و توابع رشته‌ای بدون نیاز به حلقه بسیاری از گزارشات و لیست های مرکب از رکوردهای بانک تولید می‌شود.
19- صفحه استاتیک: یکی از مزایای مهم این فریمورک قابلیت اجرا روی صفحات استاتیک است. این بخاطر آن است که بعد از لود صفحه طبق درخواستی قالب توسط سرور برگشت داده می‌شود. این مزیت امکان مدیریت حجم بالایی از درخواستها را داده و ساخت قالب صفحه طبق مشخصات کلاینت را مهیا می‌کند.
20- قابلیت بالا در REST API: این معماری توانایی بالا در ایجاد URLهای مناسب برای پیاده سازی منطق کسب و کار بر اساس REST API دارد. URLهای ایجاد شده طبق یک فرمت ساده و ثابت می باشد. تنها شناسه SP و مقدار پارامترهای SP وجود دارد. بدین ترتیب از به عنوان یک مرکز سرویس گرای فوق العاده منعطف می تواند به منابع داده ای متعددی متصل شود.
21- ساخت UIهای شخصی شده: قابلیت ایجاد UI شخصی شده و انتخابی هر کاربر. با توجه به اینکه کدهای HTML مربوط به UI در بانک ذخیره می شود بنابراین خیلی ساده می شود UI اختصاصی برای هر کاربر در نظر گرفت. بی آنکه نیازی باشد که فایلهای فیزیکی به سامانه اضافه شود.
22- مدیریت ساده فعالیتهای کاربران: از آنجا که در معماری SP-Based همه درخواستها از یک کانال عبور می کنند بنابراین عملیاتها و تعاملات کاربران بسادگی و ساده ثبت و مانیتور می شود و خیلی راحت براساس پارامترهای متنوع مثل بازه زمانی، نوع عملیات و دیگر مقدار پارامترهای ارسالی و موجود در سرور می توان فیلترهای مختلف را اعمال کرد.
22- افزایش امنیت اجرای درخواستها: از آنجا که استور پروسیجرها ذاتا در مقابل Sql injection ایمن هستند بنابراین معماری SP-Based نیز در مقابل این حملات ایمن است. از طرف دیگر چون سرورهای بانک اطلاعاتی اکثرا سرورهای فاقد اینترنت هستند و مستقیما از طریق کاربر قابل دسترس نیستند بنابراین دسترسی به سورس کدهای نیز محدودتر شده اند.
23- قابلیت استفاده مجدد بالا: یک روال ثابت می تواند توسط زبانها و فریمورکهای مختلفی فراخوانی و مورد استفاده قرار گیرد. علاوه بر آن در سطح برنامه و بانک اطلاعاتی می توان خیلی سریع و راحت می توان قطعه کدهای موجود در استور پروسیجر و توابع را مورد استفاده قرار داد. در تغییر فریمورک و زبان سامانه جلوی بسیاری از دوباره کاری ها می گیرد و براحتی می توان به آنها منتقل شد.
24- تخصصی تر شدن وظایف: در این معماری وظایف براحتی قابل تفکی است بنابراین وظایف تخصصی تر شده و برنامه نویسی در سطح DB به صورت تخصصی دیتابیس را ایجاد و نرمال سازی می کنند. SPهای مناسب را می سازند و به بهترین شکل optimize کرده و در آخر تست می کنند. در حالت معمول برنامه نویسان سطح میانی از دانش بالایی برای این موارد برخوردار نیستند.
25- حداقل شدن خطاهای Syntax: استور پروسیجرها امکان چک کردن syntax کوئری را بیشتر دارند به نسبت Raw Query ها در نتیجه خطاهایی کمتری بروز می کند. نوشتن کوئری در لایه میانی اکثرا به صورت رشته ای صورت می گیرد که بررسی خاصی روی آن صورت نمیگیرد و بسیاری از خطاها تا اجرا نشدن آن مخفی می ماند.
26- کنترل دسترسی به کدها: بطور معمول به سختی می توان مرز بین دسترسی توسعه دهندگان به سورس کدها را مشخص کرد در شرایطی که برخی از کدها، کدهای پایه ای هستند. علاوه بر آن دسترسی به بانک اطلاعاتی نیز معضل جدی تری است. در این معماری براحتی می توان برای توسعه دهندکان بر اساس نوع عملیات و ماژول سطح دسترسی به سورس کدها را مشخص کرد و دسترسی به منبع داده ای را هم کنترل نمود.
27- تست پذیری بهتر: SP بخاطر اینکه دارای خطوط کد کمی هستند به همدیگر وابستگی نداشته و روی هم اثر سوء نمی گذارند بنابراین بسرعت و بخوبی قابل تست هستند. هر چه میزان کد افزایش می یابد باگهای بالقوه هم مخصوصا در ORM با افزایش لایه های کدنویسی زیاد می شوند.
28- حداکثر استفاده از امکانات RDBMS: استفاده از ORMها باعث می شود استفاده از تمام امکانات RDBMS ممکن نباشد یا سخت باشد. در صورتی که کدنوسی در SP این امکان را می دهد براحتی و بسرعت از امکانات گسترده RDBMS دسترسی داشته باشیم.

5- چالشها و فرصتهای استفاده از SP-Based

عدم استفاده از ORM: استفاده از ORM ما را به استفاده بیشتر از OOP نزدیکتر می کند و برنامه نویسی حول ایجاد کلاسها، مدلها و اشیاء کار می کند. اما در فضاهایی که منطق کسب و کار بیشتر در SP قرار داد باعث می شود یک لایه بر پیچیدگی کدنویسی اضافه شود. بنابراین کسانی که طبق ORM کار می کنند سعی می کنند از استفاده از ORM جلوگیری کنند. از طرفی استفاده از ORM برای پیاده سازی کوئری ها به نسبت SP کار را پیچیده تر می کند و پیاده سازی را سخت تر می کند.
افزایش بار روی DB: بسیاری از توسعه دهندگان بر کدنویسی مبتنی بر SP مخالف هستند چون بار روی DB را مضاعف میکند. این ادعا صحیح نیست. اولا در معماری SP-Based درخواستهایی که نیاز به محتوای مرتبط با منبع داده ای ندارند وارد DB نمی شود. در ثانی کدنویسی SQL با توجه به ماهیت آن و ارتباط بی واسطه با منبع داده ای باعث حذف بسیاری از دستورات لایه میانی مثل دستورات اتصال، حلقه ها، شرطها، تعریف کلاسها و متغیرها می شود. طوری است که برای ایجاد گزارشها که به طور معمول نیاز به حلقه و پردازشهای زیادی دارد بدون نیاز به هیچ حلقه ای تولید می شود.
علاوه بر آن در حالت عادی ترافیک روی شبکه برای تعامل با DB بسیار بالا می باشد گاهی برای اجرای یک درخواست بارها نیاز است تا لایه میانی سراغ DB برود. این در شرایطی است که تقریبا وب سرور کاری به جزء توزیع (Dispatch) کردن درخواستها به DB ندارد. بنابراین بار پردازش روی وب سرور را بسیار کاهش می دهد.
مشکل Debug کردن SP: برنامه نویسی در لایه میانی و تحت فریمورکهای متداول باعث شده امر خطایابی و رفع خطا با ابزارهای موجود تسهیل شود. این ایراد بر SP وارد است بخوبی کدهای لایه میانی قابل خطایابی نیست اما ما در ابتدای راه هستیم و سعی داریم با تولید یک web based IDE این مشکل را کامل مرتفع نماییم و حتی بهتر از برنامه نویسی در لایه میانی این مشکل را هندل نماییم برای مثال ما جزئیات کاملتری از مشکل ارائه دهیم مثل پارامترهای ارسالی کلاینت نحوه مقدار دهی پارامترهای SP، نمایش خطی که دجار مشکل شده و ارائه پیشنهاد برای رفع آن و تصحیح برخط آن بدون نیاز به کامپایل و مراجعه به محیط کدنویسی و درگیری با فایلهای متعدد.
عدم ارائه راه حلی مناسب CI/CD: این مورد از افتخارت SP است چون بدون نیاز به کامپایل سریعا تغییرات اعمال می شود. بنابراین برنامه های پیچیده ای که دائم بایستی بروزرسانی شوند با کمک این معماری می توانند خیلی راحتر و سریعتر نسخه های جدید و اصلاحات را ارائه دهند. از آنجا که منطق کسب و کار در این فریمورک کاملا در استور پروسیجرهاست حتی تعیین ویو سامانه در استور پروسیجر وجود داره بنابراین کمتر نیاز به ایجاد تغییرات در لایه میانی و کامپایل و پاپلیش هست بنابراین یک جریان دائمی از توسعه رخ میده.

دوستان عزیز منتظر ارسال نظرات و ارزیابی فنی تون هستم