معرفی و تاریخچه فریمورکSP-Based (مبتنی بر استور پروسیجر)

1- مقدمه

در این راهنما روشی ابتکاری جهت توسعه سامانه های نرم افزاری در اختیار مدیران پروژه، توسعه دهندگان، مدیران بانکهای اطلاعاتی و تمام کسانی که در توسعه سامانه های نرم افزاری نقشی دارند عرضه میکنیم. رویکرد ما توجیه فنی هر بخش و مقایسه با روشهای مرسوم است، بدون اینکه دچار تعصب شویم. ما قصد نفی هیچ فریمورک دیگری را نداریم تنها با دانشی که کسب کرده ایم سعی داریم نقاط ضعف قوت انواع فریمورکها را با فریمورک SP-Based مقایسه بررسی کنیم.

وجود روالها وکدهای تکراری و فرمالیته در توسعه برنامه آزاردهنده هستند. شاهد این حرف آن است که پر کاربردترین کلیدها در ORMها کلیدهای Ctrl+C و Ctrl+V هستند. ما در معماری SP-Based سعی کردیم با ایجاد موتوری در کلاینت و سرور این امور را با خودکار سازی حذف کنیم. هدف اول آشنا کردن توسعه دهندگان به نقش SP در تسهیل توسعه برنامه هاست. هدف دوم متمایل کردن توسعه دهندگان به انتقال منطق کسب و کار از لایه میانی به SP است طبق استانداردهای تعیین شده است و هدف نهایی توجیح و آموزش کامل کدنویسی تحت فریمورک مبتنی بر SP است. (شعار ما اینه که ما بهتون ماهیگیری یاد میدهیم ماهی بهتون نمیدیم)

2- معماری نرم افزار

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

دو بحث مهم در معماری نرم افزار، ساختار و رفتار است. کارفرما همواره انتظار رفتار مناسب دارد و با ساختار کاری ندارد. این نباید باعث شود تا تیم توسعه بدون رعایت استانداردها و قواعد پیاده سازی کنند. رعایت استانداردها و قواعد باید تا حد امکان وابسته به شخص یا ابزار خاصی نباشد. فریمورک SP-Based هدفش آن است ساده ترین ساختار را ارائه دهد بدون آنکه در پیاده سازی رفتار موردنیاز کارفرما خللی وارد شود.

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

3- فریمورکهای نرم افزاری و ORMها

فریمورکها مجموعه ای از کتابخانه ها، کدهای از پیش نوشته شده و قواعد هستند که باعث تسهیل در توسعه سامانه های نرم افزاری شده و از تولید بسیاری از کدها جلوگیری میکنند. در نتیجه کمک میکنند توسعه دهنده بیشتر زمان خود را صرف توسعه و پیاده سازی نیازمندیهای نرم افزار کند. فرض کنید از شما خواسته شود یک کاغد A4 را به قطعات مربعی 5میلیمتری تقسیم کنید این کار را به سرعت با تا زدن دستی و برش انجام میدهید، اما اگر بخواهند برای 1000 کاغذ این کار را انجام دهید نیاز به یک ابزار مناسب دارید تا از تکرار عمل دستی جلوگیری کنید. در توسعه سامانه های کوچک هم به صورت دستی می توان یک سایت را بالا آورد اما برای توسعه یک سامانه بزرگ نیاز به فریمورک است تا از کدنویسی های تکراری و ملال آور جلوگیری شود.

بسته به زبانی انتخابی برنامه نویس فریمورکهای متعددی وجود دارد. به عنوان مثال برای php، لاراول، برای c#، EF و برای جاوا، اسپرینگ. وظیفه اصلی فریمورکها ارائه کدها، ابزارها و دسترسی هایی است که باعث می شود توسعه دهنده با موارد سطح پایین برای اجرای درخواستها درگیر نشود. به عنوان مثال بسیاری از فریمورکها دارای بستری برای ارتباط بهتر با پایگاه داده هستند که به اصطلاح ORM گفته میشود. ORMها اشکالات دیگری هم دارند که در فصول آینده به آن بیشتر اشاره می شود.

اکثر فریمورکها برنامه پیاده سازی شده را وابسته به استانداردها و قواعد خود میکنند. در نتیجه مهاجرت به فریمورک جدید را پر هزینه میکنند. فریمورک SP-Based در لایه میانی کدنویسی بسیار اندکی برای هندل کردن درخواستها به صورت متن باز دارد. منطق مربوط به هر عملیات که اشتراک با رولهای پیاده سازی شده ندارد در SPها پیاده سازی شده و در نتیجه مهاجرت به بستر جدید و فریمورک دیگر را ساده و کم هزینه می کند.

4- استور پروسیجر (Stored Procedure)

استور پروسیجرها قطعه کدهایی هستند که در اکثر DBهای رابطه ای وجود دارند. SP با زبان استاندارد SQL نوشته میشود. در DBهای مختلف تفاوتهایی در پیاده سازی SP وجود دارد اما اصول یکسان است. SP مزایایی چون سرعت ریسپانس بالا، کپسوله کردن تمام دستورها و کوئری های عملیاتها در یک بسته، مناسب برای اجرایکوئری های پیچیده، قابلیت استفاده مجدد و کم شدن Round Trip و ترافیک شبکه را دارد. SPمیتواند در بستر شبکه توسط انواع مختلف کلاینتها با زبانها و معماریهای مختلف فراخوانی شود. اعمال تغییرات در آن باعث میشود تمام کلاینتها از آخرین بروزرسانی استفاده کنند.

پیاده سازی پروژه های بزرگ و دیتا سنتریک بدون وجود SP کار بسیار مشکلی خواهد بود. در یک نمونه برای ایجاد 1000 کد تخفیف منحصر به فرد در بسترORMبیش از دو دقیقه زمان صرف شد ولی در یک استور پر.سیجر بهینه شده تنها 8 ثانیه زمان برد. یا مثلا در اجرایترانزکشنهاکه باید روی جداول متعدد اعمال شود با کمک استور پروسیجر خیلی ساده عدم موفقیت اجرای تمام یا بخشی از عملیاتها هندل می شود. همچنین کوئریهایی که حجم داده ی زیادیرا برمیگرداند بهتر است در استور پروسیجر کدنویسی شود.

اجرای کوئری های به صورت ad-hoc معایب فراوانی دارد. در جدول زیر مقایسه ای بین این نوع اسکریپت نویسی و اسکریپت نویسی تحت SP بیان شده است. در پروژه های واقعی و بزرگ اکثرا با کمک ORM ارتباط با دیتابیس مدیریت میشود. اما این روش مشکلاتی مثل عدم بهینه بودن و افزایش کدنویسی دارد که در آینده بیشتر بحث می کنیم.

5- تاریخچه فریمورک SP-Based

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

6- فریمورک SP-Based

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

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

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

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

معماری SP-Based ترکیبی از معماری‌های مطرح است که اکثر مزایای آنها را جذب و اکثر معایب آنها را رفع کرده است، در معماری لایه‌ای جذب مزیت جدا بودن کدها و رفع مشکل کدهای انبوه و تکراری،از معماری رویدادگرا جذب ایجاد صف برای دسته بندی عملیاتها و رفع مشکل کانالهای متعدد هندل رویدادها، از میکروسرویس و میکروکرنل جذب هسته کوچک و رفع مشکل وابستگی اجزاء به هسته را را انجام داده است.