https://virgool.io/feed/@iranerpgroup برنامه نویس محیط های مختلف از تحت داس، ویندوز، وب و دیتابیس هستم. مولف دو کتاب تخصصی و مبتکر فریمورکی مبتنی بر استور پروسیجر که هدفش حداقل کردن کدنویسی و هزینه توسعه و پشتیبانی می باشد. fa 2026-06-10 12:56:51 https://files.virgool.io/upload/users/302142/avatar/avatar.png?height=120&width=120 https://virgool.io/@iranerpgroup https://virgool.io/@iranerpgroup/%D8%B9%D8%A7%D8%B4%D9%82%D8%A7%D9%86%D9%87-%D8%A7%DB%8C-%D8%A8%D8%A7-%D8%AA%D8%A7%D8%A8%D8%B9-%D8%A8%D8%A7-%D8%A7%D8%B1%D8%B2%D8%B4-split-eiqmn2zdnv28 ای که رشته های خام و ناخوانای مرا به شکل مرتبی در کلاینت و سرور ارائه می دهیاگر تو نبودی مجبور بدونم رشته ها را کارکتر به کارکتر پیمایش کنم و کورمال کورمال بین هزاران کارکتر ساب استرینگهایی صورت دهم که نتیجه آن معلوم نبود درسته که امروزه با ورود فرمتهای جدید مثل jSon قدر تو معلوم نیست اما بر هیچ کس سادگی تو پوشیده نیست ، بی ادعا خیلی ساده هر بخشی از رشته را بخواهیم در اختیار قرار میدهیمیتوانیم هر بخشی را با هر چیزی دیگری جایگزین کنیم ، کمک میکنی رشته خشک سروری و کلاینتیی را برای پاسخگویی خوب به درخواستها تفسیر و پردازش کنیمبا ورود XML و jSon وجه خود را از دست داده ای اما راحت کار با تو برای من باارزش استحتی عقب مانده ترین زبانها هم تو را می شناسند به امید فزونی یافتن توابعی که مانند تو کارآمد و ساده باشندپ ن: فریمورک #SP_Based (#قائم) با استفاده از متنهای غیر فرمت بندی شده با کارکترهای خاص (مثل © - ¥ - ¢ - ¬)رشته های ورودی به سرور و کلاینت را پردازش می کند. این قابلیت امکان رندرینگ عالی گزارشها به صورت منعطف و مقداردهی پارامترهای استور پروسیجر را به صورت پویا را فراهم کرده است. امکان پیاده سازی فریمورک در انواع زبانها نیز فراهم شده است. این تفکیک بخشهای رشته ها با استفاده از تابع split در جاوا اسکریپت در کلاینت و سی شارپ یا هر زبان سروری دیگر در وب سرور انجام می شوداین قابلیت بار پردازشی زیادی از روی سرور برداشته است mahdi hoshmandi mahdi hoshmandi Tue, 22 Jun 2021 17:28:46 +0430 https://virgool.io/@iranerpgroup/%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9-%D8%A8%D9%88%D9%85%DB%8C-%D9%82%D8%A7%D8%A6%D9%85-%D8%AF%D8%B1-%D8%A7%D9%86%D9%82%D9%84%D8%A7%D8%A8-%D8%B5%D9%86%D8%B9%D8%AA%DB%8C-4-snt8tkd7ot97 امروزه فریمورکهای مختلفی جهت توسعه سامانه های نرم افزاری با رویکرد انقلاب صنعتی 4 معرفی شده اند. هر یک دارای مزایا و معایب خاص خود هستند. برای گام نهادن به صنعتی 4.0 نیاز است تا رویکرد جدید برای توسعه سامانه های نرم افزاری اندیشده شود. رویکردی که امکان تعامل با انواع دستگاه ها و زبان های برنامه نویسی را داشته باشد. رویکردی که براحتی به منابع داده‎ای مختلف متصل شده و با حجم داده‌‎های انبوه براحتی کار کند. این رویکرد می تواند باعث ایجاد مراکز صنعتی شود که کمترین وابستگی را به نیروی انسانی داشته باشند. تعدادی از ویژگیهای فریمورک بومی قائم برای انقلاب صنعتی 4 به قرار زیر است.فریمورک بومی قائم در انقلاب صنعتی 41- فرازبانی با هسته پردازشی کوچکبا توجه به رشد سریع فناوریها و لزوم بکار گیری آنها در انقلاب سنعتی 4، فریمورک قائم خیلی راحت با فناوریهای جدید شده و آنها را پذیرش میکند. این امر بخاطر هندلر عامش در لایه میانی است که چند ده خط بیشتر نیست. از طرفی اضافه کردن امکانات جدی طبق فناوریهای فناوریهای مختلف در آن نیاز به تخصصی بالایی ندارد. این ویژگی باعث سهولت بالا در توسعه و سازگاری با اانواع کسب و کارها و محدودیت خاصی به کارفرما تحمیل نمی کند.2- هزینه پایین در راه اندازی و توسعهقسمت عمده‌ای از کدهای منطق و کسب کار در قائم با زبان استاندارد و عام SQL در استور پروسیجر انجام میشود. این ویژگی باعث آموزش راحت و بکارگیری آسان آن توسط اکثر توسعه دهنده گان شده است. بدی ترتیب هزینه جذب نیرو بسیار پایین است. از طرفی بسیاری از روالها در آن مثل کنترل سطح دسترسی، تعامل کلاینت با سرور و بالعکس، اعتبارسنجی و هندل خطاها به صورت عام پیاده سازی شده است. در انقلاب صنعتی 4 حتی شرکتهای کوچک هم بسرعت رشد می کنند و نیاز به سامانه ای با ماژولهای مختلف و زیاد دارند، فریمورک قائم براحتی امکان توسعه تدریجی سامانه ها را بوجود آورده و نیازمندیهای آن کم است.3- حداقل وابستگی به بسترهای نرم افزاری و سخت افزاریاستقلال در انتخاب بهترین بستر در انقلاب صنعتی 4 بسته به مدل کاری و نوع کسب و کار خیلی مهم است. قائم به سیستم عامل، وب سرور، یا منبع داده ای خاصی وابسته نیست. از طرفی به انواع کلاینتها میتواند خدمات دهد.، راهکار قائم ایجاد یک هسته مرکزی کوچکی است که با انواع زیرساختها سازگار میشود.4- تعامل راحت با دیوایسهایقائم بخاطر هندلر قوی و سبکی که دارد، میتواند براحتی عملیاتها را دسته بندیکند. می توان هندلرهایی به تعداد نامحدود ایجاد کرد که به گروهی از سنسورها خدمات دهد. انواع سیاستهای کنترل و عکس العملی را درقبال انواع درخواستها اعمال کرد. سنسورها برای تعامل با سرور روش ساده ای دارند و تعریف درخواستها و پارامترهای آنها در سنسورها کار آسانی است.5- رویکرد دیتا محورفریمورک قائم به خاطر روش کدنویسی آن در استور پروسیجرها عاشق دیتاست. از این رو با دیتا بخوبی میتواند تعامل داشته باشد. دیتا مهمترین دارایی شرکتها در انقلاب صنعتی 4 بدین ترتیب خیلی خوب مدیریت شده و از پس پردازش داده های حجیم هم بر می آید. mahdi hoshmandi mahdi hoshmandi Thu, 17 Jun 2021 12:43:04 +0430 https://virgool.io/@iranerpgroup/%D8%A7%DB%8C%D8%AC%D8%A7%D8%AF-%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4%D8%A7%D8%AA-%DA%A9%D9%85-%D9%87%D8%B2%DB%8C%D9%86%D9%87-%D8%AF%D8%B1-%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9-%D9%82%D8%A7%D8%A6%D9%85-fsfghifbxu5r در یک سامانه درون سازمانی ماژولهای مختلف نیاز به گزارشات متنوعی دارند. در قائم هر جداول به یک ماژول متصل شده و به صورت مستقل برای هر جدول عملیات گزارشگیری انجام میشود، فارغ از اینکه جدول پایه باشد یا واسط ارتباط بین دو جدول دیگر. جداول مجموعه ای از رکوردها هستند که شامل فیلدهای مختلفی هستند. گزارشگیری از جداول با فیلدها و رکوردهای فراوان کار پرهزینه ای است. هم از لحاظ بار پردازشی روی وب سرور و هم کدنویسی و ایجاد کوئریهای لایه دیتا و وب سرور. فریمورک قائم با تولید گزارشات در استور پروسیجر (Stored Procedure) هم بحث گزارشگیری با حداکثر انعطاف را با ایجاد پارامترهای نامحدود و مقداردهی خودکار آنها حل کرده و هم قابلیت تصمیم گیری در نمایش ستونهای منتخب در موبایل را فعال کرده است. در زیر تعدادی از مزایای رویکرد فریمورک قائم در ایجاد گزارشات را ملاحظه می فرمایید.ایجاد گزارشات کم هزینه در فریمورک قائم1- کاهش هزینه پردازشیدر سامانه های بزرگ که رکوردهای بالایی دارند و کاربران آنها فراوان است. بایستی گزارشات باحداقل کدنویسی و به صورت بهینه ایجاد شوند. در این سیستمها حتی یک خط کد اضافی و سنگین می تواند باعث مختلف شدن کار سامانه گردد. قائم توانسته حداقل کدنویسی را با ایجاد مستقیم گزارشات از طریق استور پروسیجر و کوئری فراهم کند. مورد مهم دیگر که در فریمورک قائم هندل شده است عدم ارسال HTML نهایی به کلاینت است. کلاینت رشته گزارش خام را پردازش کرده و گزارش متناسبی بسته به شرایط کلاینت و ماژول به کاربر نمایش میدهد.2- کاهش هزینه کدنویسیبه طور معمول کدنویسی ایجاد گزارشات باعث درگیری نفرات مختلفی در لایه های سه گانه می شود. ایجاد ساختار گزارش HTML در فرانت اند، ایجاد حلقه های و کدهایی برای پردازش داده های دریافتی از دیتابیس و در نهایت تهیه کوئریهای واکشی لایه دیتا، باعث هزینه بالایی در کدنویسی میشود. در کدنویسی فریمورک قائم تقریبا 90درصد حجم کدنویسی گزارشات به همان ایجاد کوئریهای مناسب برای ایجاد خروجی بر می گردد. 10 درصد باقیمانده هم صرف تنظیم پارامترهای نمایش گزارش و نشانه گذاری دیتا خروجی کوئری جهت استفاده کلاینت بر می گیرد. در نهایت کلاینت با کمک این داده ها رندرینگ را انجام میدهد.3- انعطاف در نمایشبحث نمایش گزارشات در دیوایسهای مختلف مثل موبایلها و کامپیوترها بسیار مهم است. تلاشهای زیادی صورت گرفته که گزارشات در دیوایسهای مختلف ریسیپانسیو باشند. اما باید توجه داشت که گزارشات معمول برای کامپیوتر با ستونهای متعدد اکثرا به صورت جذابی در موبایل دیده نمی شوند. در چنین شرایطی تفکیک گزارش موبایل و کامپیوتر ضروری به نظر میرسد. فریمورک قائم در رندرینگ کلاینت با توجه به پهنای نمایشگر تصمیم می گیرد کدامیک از ستونها را با توجه به تنظیمات نمایش دهد. ستونها گزارش از سرور به صورت منفک به کلاینت می رسند و کلاینت میتواند هر کدام از ستونها را به هر ترتیبی نمایش دهد.4- اعمال دامینهای داده ایدر سامانه های بزرگ که داده های آنها بسیار متنوع هستند و موجودیتهای پایه ای آنها بسیار زیاد است چاره ای جزء پارتیشن بندی داده ها وجود ندارند. مثلا در یک دانشگاه براساس دانشکده دانشجویان و در یک فروشگاه بزرگ براساس دسته بندی اجناس تفکیک داده ها صورت می گیرد. برای سرعت دهی به دریافت گزارشات دیتابیسهای متعددی برای هر یک از دامینها در نظر گرفته میشود. به طور معمول سوئچ کردن به دیتابیس مناسب در وب سرور کار بسیار دشواری است و لازمه آن نوشتن کدهای فراوان در کنترلرهای مختلف است. اما در فریمورک قائم به خاطر کانال عام پردازش درخواستها براساس نام پارامتر میتوان تصمیم گیری خودکار برای انتخاب دیتابیس مناسب برای گزارشگیری را انجام داد. مثلا در سامانه دانشگاهی روی پارامتر StdCode میتوان نگاشتی (mapping) را تعریف کرد که به ازای دریافت کد دانشجویی به سرور دانشکده مناسب سوئچ کند و گزارشگیری را در آن سرور انجام دهد. این قابلیت فوق العاده باعث افزایش سرعت اجرای درخواستها شده و کنترل دسترسی را افزایش میدهد.5-قابلیت تجمیع پویابسیاری از دیتابیسهای از تجمیع پویا به صورت زیر پشتیبانی می کنند (این ساختار مربوط به Sql Server است). این ساختار با کمترین کدنویسی امکان تجمیع مقادیری را از جداول مختلف فراهم میکند. بدین ترتیب برنامه نویس در لایه میانی لازم نیست کدهای برای ایجاد حلقه ها انجام دهد. این روال در دیتابیسهای دیگر به صورتهای مختلفی هندل می شود.Declare @res nvarchar(max)=’’Select @res += title + ’,’ from Studentنتیجه گیریایجاد گزارشات امروزه بوسیله ابزارهای زیادی در زبانهای مختلف هندل میشود. اما ایجاد گزارشاتی که برنامه نویس روی تمام اجزاء گزارش اعمال نظر کند بسیار اهمیت دارد. فریمورک قائم با ایجاد HTML خام برای گزارشات این امکان را ایجاد کرده که برنامه‌نویس بتواند گزارشاتی با حداکثر انعطاف ایجاد کند. مزیت اصلی روش قائم در ایجاد گزارشات، استفاده از مکانیزم تجمیع پویاست که فوق العاده کدنویسی را کاهش داده و هزینه پردازشی و ترافیک سرور را کاهش میدهد. mahdi hoshmandi mahdi hoshmandi Thu, 17 Jun 2021 12:39:52 +0430 https://virgool.io/@iranerpgroup/%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%D8%A8%D8%A7%D9%86%DA%A9-%D8%A8%D8%A7-%D8%AF%DB%8C%D8%AA%D8%A7%D8%A8%DB%8C%D8%B3-jbuoivcorwuk ما با این مقایسه سعی داریم مزایای فریمورک قائم در کدنویسی و مدیریت دیتا را معرفی کنیم. در زیر شباهت های بانک و دیتابیس و در ادامه رویکرد قائم را معرفی کرده ایم.مقایسه بانک با دیتابیس1- هر دو مخزن منابع حیاتیدیتا امروزه بیش از پول ارزش داشته و باعث پیشرفت بسیاری از سازمانها شده است. همانگونه که سرمایه مالی توسط بانکها بخوبی مدیریت می‌شود، در سازمانها روی دیتا این حساسیت نیست. اگر سازمانی به دیتای خود اهمیت داد اجازه نمیدهد هر دیتایی وارد مخزن شود، بی ضابطه دیتا خارج شود، دسترسی به دیتا را تسهیل و تسریع میکند. در نتیجه سرمایه‌ای داده ای خود را به دانشی برای پیشرفت کسب و کار خود تبدیل می کند.2- کنترل دسترسی در هر دودسترسی محدود و کنترل شده به منابع مالی برهمگان واضح است، اما اهمیت این داستان را به منابع داده ای اکثرا متوجه نیستند. اعمال این کنترل دسترسی به طور معمول به خاطر درگاه های فراوان برای دسترسی به منابع داده ای ممکن نیست. سازمانها برای دسترسی به منابع مالی خود بشدت حساس هستند مدیران مالی هم با تایید مدیرعامل امکان خروج وجه کلان را دارند. اما دسترسی به منابع مالی برای کلیه مدیران در سطوح مختلف تعریف شده است. هر چه دسترسی به منابع داده ای راحت و دقیق باشد کسب و کار هم سریع پیشرفت می کنند.3- هر دو محرک کسب و کار هستنبرای ارتقای یک کسب وکار لازم است منابع مالی فعالتر و درستتر هزینه شوند. اما نقش دیتا پردازش شده برای این منظور مهمتر است. مانند دارایی مالی، دارایی داده ای هم وقتی زیاد میشود قدرت تصمیم گیری کسب و کار بیشتر میشود. بستر تعاملی سازمان برای کار با منبع داده ای باید چنان با دیتا اجین شده باشد که از کمترین داده ها بیشترین استفاده را ببرد. مانند یک سامانه بانکداری که انواع حسابهای کسب وکار، انواع سررسیدها، انواع ورود و خروجها به صورت کاملا دقیق، سریع، مطمئن و راحت صورت میگیرد.استفاده از فریمورک دیتاسنتریک قائم1-قائم فریمورک مبتنی بر دیتارویکردهای معمول کدنویسی را مبتنی اشیاء انجام میدهند. براساس این رویکرد برای هندل کردن یک عملیات نیاز است سرویسها، اکشنها، رویدادها و اشیاء فراوانی ایجاد شوند. این رویکرد مثل ایجاد یک صندوق درون سازمانی برای هندل کردن عملیاتهای مالی می باشد. در صورتی که رویکرد کنترات کردن بانک مالی در بانک دیگر ثابت شده است.قائم رویکرد در مقابل دیتا در منبع داده ای مثل رویکرد پول در بانک است. همانطور که سیاستهای مالی در سامانه بانکداری به بهترین شیوه هندل میشود سیاستهای داده ای هم در منبع داده ای خیلی خوب مدیریت میشوند. رویکرد فریمورک قائم ایزوله کردن کلیه عملیاتهای مرتبط به دیتا داخل منبع داده ای و اکثرا به صورت SP میباشد.2- درگاه واحد برای دسترسی به دیتاهمانطور که بانکها به هر مشتری برای دسترسی به منابع داده ای درگاه مستقلی ارائه نمیدهند. قائم هم درگاه‌های متعددی برای هر ماژول برای دسترسی به دیتایش در اختیار نمی گذارد. این مزیت باعث شده کار مدیریت داده به صورت تخصصی توسط خود بانک اطلاعاتی انجام شود. قائم درگاهی مطمئن در اختیار ماژولها می گذارد که با کمترین درگیری جزئیات عملیات داده ای خود را انجام دهند. با محدود شدن راه های نفود اعمال سیاستهای داده‌ای و کنترل دسترسی مطمئن، راحت و سریع شده است.3- کدنویسی حول دیتابه طور معمول دیتا حول کدها پیاده سازی می شوند یعنی کدهای انبوهی نوشته شده که دیتایی در آن وجود دارد. این رویکرد باعث افزایش کدها و ایجاد کدهای حاشیه ای برای دسترسی به داده ها می شود. قائم کدنویسی SQL را حول دیتا اعمال میکند. بسته به نوع عملیات SPهای مختلفی برای ماژولها تولید میشود، دستورات اجرای عملیاتها عمدتا با کوئرهایی و دستورات if هندل می‌شوند. در نتیجه کدهای حاشیه‌ای، تعریف متغیرها و کلاسها برای اجرای عملیاتها در هندلر لایه میانی به حداقل می رسد. مگر در هندلر لایه میانی که به صورت کاملا تخصصی و محدود مدیریت میشوند.نتیجه گیریاگر به دنبال راه اندازی سامانه درون سازمانی در هر مقیاسی هستین، بهترین بستر را برای آن ایجاد کنید، چون دسترسی به داده به عنوان ارزشمندترین دارایی سازمان نقش کلیدی در آینده سازمان داشته و تغییر آن مهلک ترین ضربه را به کسب و کار می‌زند. بستری که ساده، قدرتمند و سریع باشد. دیتاسنتریک بوده و در مقابل تغییر تکنولوژی انعطاف داشته باشد. mahdi hoshmandi mahdi hoshmandi Thu, 17 Jun 2021 12:37:43 +0430 https://virgool.io/@iranerpgroup/%D9%85%D8%B2%D8%A7%DB%8C%D8%A7%DB%8C-%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9-sp-based-jazkuh2cp2df در این مقاله به بررسی مزایای فریمورک SP-Based خواهیم پرداخت. مزایای شناسایی شده برای این فریمورک بالای 30 مورد است که در اینجا 10 مورد که برخی مشتمل بر چند ریز مزیت هستند را تشریح می کنیم. این مزایا در عمل باعث میشود که هزینه و زمان توسعه کاهش یافته و انعطاف پروژه در مقابل تغییرات افزایش یابد.مزایای فریمورک SP-Based1- حداقل کدنویسی با کدنویسی مجازیکدنویسی معمول باعث افزایش چشمگیر فایلها و پوشه های پروژه شده که مدیریت نسخه ها و تغییرات آن نیاز به نرم افزارهای Version Control مثل GIT دارد. در پروژه های بزرگ هزاران فایل و پوشه ایجاد میشود که بسیاری همنام هستند و توسط تیم توسعه مدام باید Push و Pop شوند، چالشهای اساسی در Conflict و merge به چشم میخورد. راه اندازی پروژه با کلی فایل حتی branch شده به صورت لوکال توسط تک تک افراد تیم حتی یک آزمونگر ساده هزینه توسعه را افزایش میدهد. طبق اصل زیر این کار اصولی نیست.فریمورک SP-Based برای حل چالش فایل محوری راهکار کدنویسی مجازی مبتنی بر SP را ارائه داده است. SPها در این فریمورک حداقل خطوط پیاده سازی عملیات CRUD را دارند. ساده و کم حجم هستند و اثر جانبی روی قطعه کدهای دیگر ندارند بنابراین اغلب نیاز به VC ندارند. در وب سرور و کلاینت از تکرار کدهای فرمالیته برای نگاشت درخواست به SPجلوگیری شده است. با گسترش ابعاد پروژه لایه میانی رشد چندانی نداشته و مدیریت آن ساده است.اصل KISS میگوید اینقدر باید کدنویسی را ساده انجام کرد که همه فهم باشد. این فریمورک بخاطر جدا کردن منطق کسب و کار به بخشهای کوچک و قابل مدیریت با حداقل کدنویسی توانسته در عین حال سادگی کدها را نیز حفظ کند. کدهای موجود در SPها برای اکثر عملیاتها به 5 خط هم نمیرسند. کدهای موجود در لایه میانی و کلاینت هم یک خط مشی یکسان را برای همه درخواستها دنبال میکنند که بررسی و توسعه آن ساده می باشد.2- فرا زبانیاز آنجا که فریمورک SP-Based دارای کدهای پایه ای اندک در لایه های کلاینت و سرور است بنابراین می تواند در زبانهای مختلف چون c#، php، جاوا و ... پیاده سازی شود. با بانک اطلاعاتی اوراکل، Sql Server و همه DBهای رابطه ای که SP را پشتیبانی میکنند کار کند. انواع کلاینتها هم می توانند از این فریمورک به خوبی استفاده کنند.کلاینتهای متعددی از انواع مختلف از مرورگرها، Appهای موبایل، دیوایسها و حتی سامانه های همکاری میتوانند به مجموعه ای از هندلرها تحت این فریمورک متصل شوند. این هندلرها میتوانند با زبانها و پلتفرمهای مختلف پیاده سازی شده باشند. هر HTTP هندلری سروری هم می تواند مستقلا به تعداد نامحدودی منبع داده ای متصل شود.فرازبانی بودن این فریمورک میتواند اتحاد مبارکی بین توسعه دهندگان با زبانها مختلف در سطح سازمان، هلدینگ یا سازمانهای مختلف با هم ایجاد کند. مجموعه بزرگی از توسعه دهندگان می توانند برنامه هایی را توسعه دهند که از فریمورک SP-Based قدرت گرفته باشند، در این صورت سهولت بالایی در استفاده اشتراکی و کنترل شده از عملیاتهای موجود در هر برنامه قابل انجام است. بدون اینکه توسعه دهندگان نیاز باشد کار خاصی انجام دهند تنها با تعیین سطح دسترسی میتوانند همانند خود برنامه میزبان از دیتاها و کدهای موجود در آن به صورت منعطف و کنترل شده استفاده نمایند. از طرف دیگر صرفه جویی زیادی در کاهش هزینه تهیه سرورها برای ذخیره و پردازش داده ها صورت خواهد گرفت. حداقل داده ها در سرورهای هر بخش ذخیره خواهد شد. میتوان سرورهای مرکزی برای ثبت داده های پایه داشت.3- احراز هویت و کنترل دسترسی خودکاراز آنجا که تمام درخواستها از یک کانال واحد در سرور عبور می‌کنند پیاده سازی انواع سیاستهای امنیتی و کنترل سطح دسترسی خیلی ساده صورت می‌گیرد. هر کاربری که در برنامه لاگین میکند کدی دریافت میکند که در جدولی شناسه عملیاتهایی که میتواند اجرا کند مشخص شده است، بنابراین احراز هویت برای اجرای عملیاتها توسط چند خط کد محدود با یک کوئری ساده صورت می‌گیرد.رولها نیز مجموعه ای از دسترسی های اجرای عملیاتها میباشند. که براحتی به هر کاربر قابل تخصیص است. دسترسیهای تعریف شده برای هر کاربر به ازای هر عملیات قابلیت انعطاف بالایی دارد پارامترهای مختلفی چون تاریخ شروع و انقضا، IP مجاز اجرا و یا حتی دفعات اجرا در آن قابل تعریف است. این پارامترها مخصوصا برای برنامه های تجاری که عملیاتها و دسترسی های زیادی دارند اهمیت بیشتری دارد. چون براحتی میتوانند انواع سیاستهای کنترلی را اعمال کنند. به عنوان مثال مانند مصرف انرژی قبض صادر کنند و محدوه مجاز را تعریف کنند و امکان محاسبه تصاعدی اجرای هر عملیات را هم در نظر بگیرند.4- اعتبارسنجی مقادیر ورودییکی پر چالشترین کارهای توسعه نرم بخاطر تکراری و سطح پایین بودن آن، اعتبارسنجی مقادیری ورودی فرمها میباشد. کنترل ورودی در کلاینت و نمایش پیغام مناسب و فوکوس دادن کاربر روی المان یا بخش مرتبط و سرور هم چون نمیتوان به اعتبارسنجی کلاینتی اکتفا کرد بایستی اعتبارسنجی تکرار شود که اکثرا نیاز به تخصص فنی بالایی ندارند.اعتبارسنجی در فریمورک SP-Based به شکل جالبی هندل میشود. در سمت کلاینت با توجه به کلاس المانهای ورودی به صورت خودکار اعتبارسنجی، نمایش پیغام و فوکوس دادن انجام میشود. در سمت سرور نیز اعتبارسنجی مقادیر دریافتی به صورت خودکار با توجه به نوع پارامتر ورودی SP مجری درخواست بدون نیاز به نوشتن کد اختصاصی صورت می گیرد. این عدم استفاده از نوع داده ای مربوط به لایه میانی باعث سهولت و دقت بیشتری در اعتبارسنجی ورودی شده است. مثلا برای تعیین فیلد رشته ای به طور کلی در زبانهای لایه میانی نوع داده ای String در نظر گرفته شده است. در صورتی که در بانک اطلاعاتی طول رشته هم اهمیت دارد. اعتبارسنجی پویا هم از دیگر مزایای این معماری است در فصول بعدی نحوه پیاده سازی آن شرح داده شده است.5- پیاده سازی تراکنشهای پیچیده و Long Livedیکی از چالشهای بزرگ بسیاری از برنامه ها قابلیت پیاده سازی تراکنشهای پیچده و 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ها باید کلی توابع تو در تو برای دریافت خروجی مناسب نوشته شود.5- رهگیری اجرای درخواستها و کشف سریع خطاهابه طور معمول رهگیری و کشف خطاهای زمان اجرای برنامه ها کار ساده ای نیست، هر چند بسیاری از فریمورکها مکانیزمهایی برای خودکار کردن آن ارائه داده اند، اما همچنان به صورت کامل و ساده امکان هندل کردن آن را ندارند. بنابراین توسعه دهندگان برای آنکه برنامه در نقطه ای از اجرا دچار توقف و نمایش خطای سیستمی نشود بایستی بوسیله ساختارهای try-catch اقدام به مدیریت خطاها کنند. لاگ کردن خطاها و ثبت جزئیات خطا هم از چالشهای دیگر رهگیری خطاهای سامانه است.فریمورک SP-Based دارای یک HTTP هندلر واحد برای اجرای تمام درخواستهای کلاینت میباشد که اگر به خطا بخورد بسادگی با ساختار try-catch جزئیات خطا ثبت میشود. این کار از دوباره کاری و تکرار متعدد کدهای هندل کننده خطا و ثبت لاگ جلوگیری می‌کند. این مکانیزم باعث محدود شدن بروز خطا، رفع آسان آنها و عدم درگیری با خطاهای پیچیده و گسترده ORMها میشود. همچنین امکان اعمال انواع سیاستهای رهگیری و حل خطا مثل اطلاع رسانی سریع و تعریف تسک برای آنها فراهم میشود.افزون بر این به علت ماهیت ایزوله بودن کدها در SPها خطاهای رخ داده خیلی سریع شناسایی و رفع می‌شوند و بدون نیاز به کامپایل مجدد برنامه، امکان خدمت رسانی خواهد داشت. بنابراین زمان downtime سامانه خیلی پایین است. اشکال اساسی مطرح ضعف در تریس SP است که بخاطر محدود بودن خطوط اکثر SPها (کمتر از 5 خط) این مشکل چندان جدی نیست.خطاهای احمقانه ای که فریمورک میگیرد6- هندل کردن عملیاتهای FCRDE سرور با متدهای HTTPدرخواستهای 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 و شناسه ماژول را همراه داشته باشند. متد از روی کلاس المان کلیک شده و شناسه ماژول هم از روی متغیرهای داخلی مرورگر تعیین میشود. زمانی که فرم جدید یا ویرایش مربوط به یک ماژول فراخوانی میشود شناسه ماژول جدید ثبت میشود.7- تسریع و تسهیل کردن کدنویسیتسلط به کدهای هسته مرکزی این فریمورک بخاطر ساختار ساده و مشخصی که دارد، براحتی قابل انجام است. متدها، متغیرها، کلاسها و آیتمهای خیلی کمی وجود دارد. اصل برنامه یعنی اجرای درخواستهای کلاینت، بصورت خودکار از روی نام ماژول و متد HTTP به SP مربوطه نگاشت میشود. بخاطر ساختار دسته بندی عملیاتهای ماژولها توسعه دهنده سریع می تواند عملیاتهای پیاده سازی شده هر ماژول را تشخیص دهد و عملیاتهایی که هنوز پیاده سازی نشده است را کامل کند.از آنجا که زبان SQL ترفندهای جالبی برای پیاده سازی شرطها و حلقه ها دارد. در نتیجه برای تولید گزارشات و فیلترینگهای مربوطه نیاز به کدنویسی کمتری میباشد. در حالت معمول نیاز است که ساختارهای حلقه ای و شرطی متعددی در لایه میانی برای ساخت انواع گزارشات و اعمال فیلترینگ روی آنها انجام شود.یکی از معیارهای اصلی در کاهش هزینه نیروی انسانی، پشتیبانی و توسعه، سهولت و سادگی در کدها میباشد. هر چه کدها کمتر باشد مدیریت آن ساده تر است در نتیجه سریعتر برنامه توسعه یافته و نیروی متخصص با سطح سواد پایینتری نیاز دارد.8- معماری تک صفحه ایدر معماری MVC هر ماژول ویوهای مستقلی دارد که باعث تولید فایلهای متعدد CSS، JS و HTML میشود. پیاده سازی معماری تک صفحه ای هم باعث افزایش چشمگیر پیچیدگی شده و اصولی نیست. بنابراین هر ماژولی باید به صورت مستقل کدهای کلاینتی و سروری ایجاد کند. در صورتی که بسیاری از روالها مثل اعتبارسنجی، تعامل با سرور و پردازش درخواست روال عام و یکنواختی دارند.فریمورک SP-Based برای پیاده سازی ماژولها و عملیاتهای برنامه به صورت تک صفحه ای اقدام میکند. یعنی برنامه تنها یک ویو دارد. فایل ویو فقط شامل چهارچوب اصلی قرارگیری هر بخش است. با شروع اجرای عملیاتها محتوای متناسب مثل نوار منو، داشبورد و ... در آن به صورت پویا توسط SP پر میشود. در ادامه بعد از انتخاب هر گزینه در نوار منو یا داشبورد به صورت پویا محتوای HTML عملیات درخواستی در کانتینر (مفهوم کانتینر در فصل 5 بررسی میشود) قرار داده میشود.هندل کردن تعامل با سرور بسته به متد عملیات درخواستی از یک درگاه و کانال عبور میکند. بدین ترتیب با کدهای محدود جاوا اسکریپتی میتوان انواع سیاستهای تعاملی با سرور را در جهت حداکثر کردن اعتبارداده ها، ارائه بهترین تجربه کاربری، انتخاب فرمتهای مناسب ارائه داده، رندر کردن صحیح و منعطف خروجی و .... اعمال کرد. این سبک کدنویسی امکان پاسخگویی به حجم بالایی از درخواستها را با درگیری حداقلی سرور ایجاد می‌کند.9- توسعه پذیری بالابرنامه نویسی OO و ORM حساسیت زیادی روی تعریف دقیق مدلها، فیلدها، مقداردهی، ارث بری و ... دارد و چالشهایی هم مثل بروز اثر جانبی دارد. بدین ترتیب برای کنترل ورودی کلاینت، پردازش درخواست و ارسال خروجی مناسب هزینه پردازشی و کدنویسی بالایی را تحمیل میکند. به عنوان مثال لازمه اجرای یک عملیات ساده مثل insert مقداردهی تک تک فیلدهای و اجرای متدهای متعدد برای دریافت شناسه رکورد درج شده میباشد. در صورتی که با دو خط کدنویسی SQL این کار شدنی است.فریمورک SP-Based از یک مکانیزم خاص به نام Lookup برای اجرای درخواستها استفاده میکند. اما به جای اینکه درخواست را به یک شی نگاشت کند آن را به یک SP نگاشت میکند. ایجاد این روال دارای دو مزیت زیر را به نسبت روال معمول دارد.- تعیین SP و DB مربوطه از روی ماژول و متد دریافتی به صورت خودکار و با چند خط کد محدود انجام میشود. جدول Lookup جزئیات کامل SP را ارائه میدهد. در مدل شی گرایی بعد از Lookup یک شی ارائه میشود که باید به صورت دستی متد مجری درخواست تعریف و مقداردهی شود، همچنین ایجاد کانشن پویا به DBهای مختلف نیز اکثرا نشدنی است.- پارامترهای ورودی SP با کمک یک حلقه به صورت خودکار تعریف و مقداردهی میشوند. اما در مدلهای شی گرایی باید دقیق فیلدهای مدل به همراه نوع داده ای تعریف شوند. مقداردهی آنها نیز مستلزم ایجاد یک شی از آن مدل و مقداردهی و انتساب دستی تک تک فیلدها میباشد.دسته بندی عملیاتهای مشابه ماژولها و تجمیع آنها از دیگر موارد افزایش توسعه پذیری این فریمورک است. مثلا ایجاد فرم جدید و ویرایش چون خروجی تقریبا یکسانی دارند و همچنین درج و بروزرسانی رکورد چون پارامترهای ورودی یکسانی دارند تجمیع شده اند. از طرف دیگر خروجی تمام SPها رشته ای است و در نتیجه هندل کردن پردازش آنها در سرور و کلاینت راحتتر است. بخاطر کدنویسی در SP از امکانات DBMS حداکثر استفاده را برده و با توسعه این کارکردها میتواند از امکانات جدید آن با حداقل هزینه بهره مند شود.این فریمورک بخاطر رویکردی که در پیاده سازی منطق کسب و کار دارد، امکان پیاده سازی پروژه ها را با انواع مدلهای توسعه چابک دارد. در نتیجه امکان شروع پیاده سازی سریع پروژه با کمترین تحلیل را داشته و هزینه تغییرات در این فریمورک پایین است. بخش مهمی از مستند سازی مربوط به کدها به صورت خودکار تولید شده و مدیریت تسکها هم به صورت سیستمی انجام می شود.10- قابلیت تجمیع با فریمورکهای دیگرتجمیع فریمورکها بالاخص در فریمورکهایی جاوایی مثل تجمیع هایبرنت و اسپرینگ جهت پیاده سازی برنامه کارآمدتر خیلی مرسوم است. فریمورک SP-Based یک فریمورک full stack است که میتواند با انواع فریمورکها تجمیع شود. این فریمورک شامل موتور پردازشگر رویدادها در کلاینت برای پوشش ویوی برنامه و HTTP هندلر برای اجرای مستقیم، سریع و ساده درخواستها با کمک SP در سرور میباشد. بدین ترتیب اگر تمام یا بخشی از برنامه با کمک SP راه اندازی شود این هندلر بخوبی میتواند جوابگوی اجرای آنها باشد.موتور پردازشگر رویدادها در پیاده سازی ویوی داینامیک مورد استفاده قرار میگیرد. امکان مدیریت عملیات ماژولها تحت یک صفحه و هندل کردن خودکار انواع رویدادهای را با کمک jQuery فراهم کرده است. برای 4 دسته رویداد اصلی برای ماژولهای مختلف عملیاتهای زیر را به صورت خودکار انجام میدهد.- نمایش فرم جدید و ویرایش: خواندن شناسه رکورد (صفر برای فرم جدید) و ارسال آن با شناسه ماژول با متد Get به سرور- ذخیره سازی فرمها: خواندن مقدار المانها، اعتبارسنجی، تجمیع مقادیر و ارسال مقادیر و شناسه ماژول با متد Set به سرور- حذف رکورد: خواندن شناسه رکورد، نمایش پیغام تایید و ارسال درخواست با متد Delete به سرور- گزارشگیری: خواندن مقادیر ورودی مربوط به فیلتر، تجمیع مقادیر و ارسال آنها به همراه شناسه ماژول با متد Patch به سرورتوسعه دهندگان با توجه به شرایط مختلفی که دارند میتوانند از هندلر کلاینتی یا سروری در کنار فریمورک مدنظر خود استفاده کنند. اما کارآمدی این فریمورک در زمانی که هر دو سمت کلاینت و سرور با هندلرهای تعریف شده پیاده سازی شود خیلی بالاتر است و پشتیبانی هم راحتر خواهد بود. mahdi hoshmandi mahdi hoshmandi Sun, 24 Jan 2021 09:40:58 +0330 https://virgool.io/CodeLovers/%D8%A7%D8%B1%D8%B2%DB%8C%D8%A7%D8%A8%DB%8C-%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9-sp-based-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-%D8%A7%D8%B3%D8%AA%D9%88%D8%B1-%D9%BE%D8%B1%D9%88%D8%B3%DB%8C%D8%AC%D8%B1-acoz5rwyyurs یکی از جذابترین مقاله های مربوط به فریمورک بی شک این مقاله است که توسعه دهندگان مختلف را درگیر خود خواهد کرد و با توجه به اکوسیستمی که در آن کار میکنند می توانند قیاس مناسبی بر فریمورک SP-Based داشته باشند. در آخر نیز از ارزیابی های صورت گرفته نتیجه گیری کرده که می تواند تصمیم گیری را برای مخاطبین ساده کند.با توسعه هر چه بیشتر فریمورکهای ORM بشدت نگرش انتقال بیزینس پروژه به داخل DB منسوخ شده است. علت آن سهولت اعمال تغییرات در منطق برنامه و ساختار DB در یک محیط میباشد. در این بخش سعی داریم یک ارزیابی دقیق، شفاف و روشن برای مخاطبین ارائه دهیم. نقاط ضعف و قوت فریمورکهای مختلف را بررسی کنیم و در نهایت نتیجه گیری مناسبی بگیریم.1- چالشهای مطرح در فریمورک SP-Basedدر این بخش چالشهای مطرح در رابطه با انتقال منطق کسب و کار در داخل DB را بررسی مینماییم. چالشهای مطرح شده در کدنویسی معمول که بخشی از کدها در لایه میانی قرار دارند و بخشی را نیز به SP منطق میکنند درست است اما این فریمورک مکانیزمی انتخاب کرده که اکثر کدهای کلیدی در SP قرار میگیرد در نتیجه بسیاری از چالشها، حل یا اثر سوء آنها به حداقل رسیده است.2- مدل توسعه Database First در SP-Basedدر قبال توسعه برنامه ها مبتنی بر ORM دو رویکرد اصلی وجود دارد. عده ای قائل به مقدم بودن پیاده سازی DB هستند. عده ای مدلها و کلاسها را مقدم میدانند و DB را بر اساس آن ایجاد میکنند. رویکردی که اصرار دارد بگوید DB تنها یک مخزن داده بوده و نباید توسعه دهنده درگیر آن محیط شود. اگر این دیدگاه به صورت افراطی دنبال شود قطعا نتیجه مناسبی نخواهد داشت.فریمورک SP-Based، ORM نیست اما با مکانیزم لوکاپی که دارد مدل Database First را دنبال میکند. به دنبال افزایش بار روی DB نیست، بلکه با تفکیک منطق کسب و کار به بخشهای مختلف تنها آن بخشی که مربوط به اجرای اسکریپتهای اسکیول است را وارد SP مینماید. به نحوی که حتی یک خط اسکریپت در لایه میانی وجود ندارد، این باعث شده تا توسعه سامانه به صورت ساختار مند پیش برود. در قیاس روشهای معمول که سعی دارد دستورات SQL را با کمک روشهای مختلف مثل LINQ در دل کدهای لایه میانی هضم کند، غافل از اینکه این کار باعث افزایش پیچیدگی و حجیم شدن کدنویسی میگردد.3- معماری میکرو سرویس در SP-Basedبرنامه هایmonolithic کل اجزاء برنامه را در یک جا قرارداده و پیاده سازی را ساده و سریع می کنند اما چالشهای زیادی در توسعه و پشتیبانی دارند. برنامه های مایکروسرویس با راه اندازی یک API Gateway عملیات ارسال درخواستها به سرویسها را انجام میدهند، سرویسها می توانند با انواع فناوریها پیاده سازی شوند. برنامه های SP-Based می توانند به صورت مونولیتیک با حفظ مزایای مایکروسرویسی تحت یک DB، هم به صورت مایکروسرویسی با تعداد نامحدودی DB میتوانند پیاده سازی شوند. سرویسها در این معماری به صورت SP پیاده سازی می شوند. مزیت این روش فاکتور گرفتن و اجرای خودکار بخش زیادی از کدهای سرویس مثل اعتیارسنجی مقادیر ورودی، اعمال شرطها و تغییر فرمت پارامتر ورودی و ... میباشد. مهاجرت دادن یک برنامه مونولیتیک بخاطر وابستگی زیاد اجزاء به مایکروسرویس بسیار دشوار است اما راحتر میتوان به SP-Based مهاجرت داد چون هر جزء در قالب SP سادتر پیاده سازی میشود.4- رستوران داری ایده آل قیاسی برای کارکرد فریمورکSP-Basedبسیاری از مساائلی که در حوزه رستوران داری مطرح است در یک برنامه تحت وب ایده ال هم به شکل دیگری مطرح است. جدول زیر به بررسی برخی از این مسائل میپردازد و نقش فریمورک SP-Based در رسیدن به چنین برنامه ای بیان میکند. در بخش نتیجه گیری میتوانید به صورت کاملتری علت این مزیتها را مشاهده کنید.-مقایسه فریمورک SP-Based با EF Coreدر این بخش دو نوع ارزیابی روی فریمورک EF Core انجام داده ایم. ارزیابی اول از لحاظ حجم پروژه و هزینه اجرا و ارزیابی دوم پارامترهای کیفی بررسی شده است. در جدول زیر ارزیابی اول، سامانه ای با 300 ماژول و 1600 عملیات فرض شده است. برای محاسبه هزینه اجرا میانگین حقوق دریافتی هر فرد در ماه 5 میلیون در نظر گرفته شده است. فایلهای سیستمی در نظر گرفته نشده است.فریمورک SP-Based در چنین پروژه ای هزینه اجرای پروژه را یک ششم کرد و زمان اجرا را هم به یک سوم کاهش داد. مهمترین علت این بهره وری بخاطر عدم نیاز به پیاده سازی مفاهیم مفاهیم شی گرایی برای پاسخگویی به درخواستها می باشد. بدین ترتیب توسعه دهنده بدون ورود به مسائل حاشیه ای، تمرکز خود را بیشتر روی پیاده سازی اصل منطق کسب و کار میگذارد.اجرای دستورات کار با DB در EFشامل 3 بخش شی مربوط به اتصال DbContext، دوم عبارت LINQ و سوم متد و دستور تبدیل خروجی مناسب است، اما در SP-Basedدستورات ثابت و اختصاصی در لایه میانی مطرح نیست. از طرف دیگر دسترسی غیرمستقیم به موجودیتهای DB است که در SP-Based به صورت مستقیم با دستورات SQL انجام میشود. در ارزیابی دوم از لحاظ پارامترهای کارکردی این دو فریمورک بررسی شده اند. میتوان گفت در همه پارامترها SP-Based بهتر عمل کرده است. اما این به این معنا نیست که ما کارآمدی EF را زیر سوال ببریم بلکه در رویکرد انتخابی بهترین عملکرد را داشته است.5-مقایسه فریمورک SP-Based با Springاسپرینگ یک فریمورک full stack است که همه لایه های درگیر پردازش درخواست را پوشش داده و به عنوان یک ORM کم و بیش همان مشکلات EF Core را دارد که در بخش قبل مطرح شد، اما یکی از موارد جالب این فریمورک که بسیار کارگشاست و باعث کوچک شدن پروژه میگردد Dependency Lookup است. این مورد خیلی به کارکرد HTTP هندلر فریمورک SP-Based شباهت دارد.یکی از مفاهیم مهم اسپرینگIoC که به بحث خارج کردن وابستگی از کامپوننت به داخل کانتینر اشاره دارد. هدف آن توسعه راحتر و هارد کدنویسی کمتر است. یکی از محبوبترین راهکاری آن در اسپرینگ Dependency Lookup است. در این روش اشیاء کامپوننتها سعی میکنند خود، وابستگیهای موردنیازشان را تامین کنند. برای این منظور ابتدا یک کانتینر ApplicationContext طبق یک فایل XML ایجاد میشود. سپس شی موردنیاز برنامه طبق تنظیمات موجود در آن فایل به صورت پویا ایجاد میشود. در زیر شی Bean از روی شی MainBean ایجاد شده است. به این فرآیند Lookup گفته میشود.در فریمورک SP-Based هم مکانیزم HTTPهندلر مشابه Dependency Lookup است. وابستگیهای و نیازهای درخواست کلاینت خیلی بیشتر و جزئی تر توسط خود هندلر تامین میشود.این جزئیات بجای جستجو درXML به صورت پیشرفته از ردیس (بانک اطلاعاتی in-memory) واکشی میشود.6- مقایسه فریمورک SP-Based با Oracle Apexما در این بخش به بررسی فریمورک Oracle Apex خواهیم پرداخت که هدفش توسعه برنامه های تحت وب مبتنی بر اوراکل است. البته بواسطه این مقایسه با معایب و مزایای فریمورکها Web Based IDE در قیاس با فریمورک SP-Based بیشتر آشنا میشویم. با کمک این فریمورکها بدون داشتن محیط توسعه تنها با کمک مرورگر میتوان سامانه وب موردنظر را با کلی صفحات، گزارشات، فرمها و ... پیاده سازی کرد.اگر بخواهیم مثالی از تفاوت فریمورکهای Web based IDE را با SP-Based بیان کنیم باید تفاوت بین سیستم عامل گرافیک محور و تکس محور را بررسی کنیم. سیستم عاملهای تکس محور برای حرفه ای ها راحتر و سریعتر است و قابلیتهای بیشتری را ارائه میدهند اما سیستم عاملهای گرافیک محور برای انواع افراد قابل استفاده بوده اما برای حرفه ای ها مناسب نیست چون انعطاف حداکثری و استفاده از حداکثر مزایای پلتفرم را ارائه نمی دهند. فریمورک SP-Based هم طرفدار رویکرد تکس محور است هر چند در فصل 9 روش پیاده سازی Web based IDE را ارائه می دهیم. در جدول زیر مقایسه ای بین فریمورکهای Apex و SP-Based صورت گرفته است.به طور خلاصه فریمورک Apex به نسبت SP-Based چند اشکال مهم دارد:- تعیین رفتار و ظاهر المانها خیلی کلی است و نمی توان براحتی استایلها و رفتارهای دلخواه را اعمال کرد- درگیری با مدیریت صفحات و چیدمان محتوای داخلی آن باعث شده اعمال تنظیمات ریز دشوار باشد- وابستگی به یک نوع دیتابیس آن هم اوراکل- عدم دسترسی به کدهای پشت پرده و دشوار بودن کدنویسی دقیق و پیچیده مربوط به عملیاتهامزیتهای Apex نسبت به SP-Based به طور خلاصه به موارد زیر بر میگردد.- ارائه انواع محتواها مثل چارتها، المانهای مختلف و ... به صورت خودکار با انجام تنظیمات گرافیکی- امکان دسترسی مستقیم به بانک و اجرای دستورات مختلف روی آن با کمک محیط تحت وب- حداقل نیاز به کدنویسی و کاربری راحتر برای مبتدی هابه طور خلاصه درست است که فریمورکهای تحت وبی مثل Apex سهولت زیادی در ساخت صفحات و ایجاد سامانه های تحت وب دارند اما در ارائه یک سامانه حرفه ای با پیچیدگیهای زیاد سربار ایجاد میکنند که باعث میشود توسعه دهنده علاوه بر قواعد خود زبان SQL و کسب و کار، باید قواعد آن محیط را هم رعایت کند و یاد بگیرد. اما گزینه مناسبی است اگر سامانه موردنظر پیچیدگی پایینی دارد و توسعه دهندگان روحیه و تجربه کار با چنین فریمورکهایی را داشته باشند.7- ارزیابی فریمورک SP-Based در انقلاب صنعتی چهارم صنعتیروال مصنوعی سازی انسان از انقلاب صنعتی و تبدیل کردن نیروی ماهیچه ای به نیروی ماشینی شروع شد. بعد از آن با ظهور شبکه های مخابراتی توانست سیستمهای عصبی یک وی را شبیه سازی کند و انقلابی در ارتباطات ایجاد کند. انقلاب صنعتی چهارم با هوش مصنوعی سعی دارد، این انسان مصنوعی را کامل کند. به طوری که ماشینی هوشمند، دقیق و سریع ایجاد کند که بتواند به سرعت عملیاتهای موردنیازش را برطرف نماید.در کلیه سیستمها سه مولفه اصلی باید در کنار هم باشند تا آن سیستم بتواند به درستی عمل کند این سه مولفه سوخت، زیر ساخت و محرک است. در وسایل نقلیه، خودرو، بنزین و راننده و در سامانه های نرم افزاری سخت افزارها، الگوریتم و دیتا است. الگوریتمها مانند محرکی هستند که با کمک دیتاها سخت افزار را به حرکت در می آوردند. در انقلاب صنعتی چهارم اپراتورهای انسانی جای خود را به دیوایسهایی میدهند که بوسیله الگوریتمهایی که از دیتا قدرت میگیرند هدایت میشوند.دیتا نقش اساسی در این انقلاب دارد، تا حدود 10 سال پیش این حد دیتا در این سطح در دسترس نبود. اما امروزه آن چنان تولید دیتا بصورت نجومی گسترش یافته که الگوریتمهای هوش مصنوعی با دقت بالایی میتوانند هدایت سامانه های مختلف را به عهده بگیرند. مثل هدایت ماشین آلات، هدایت خریداران به سمت خرید محصولات بیشتر، پردازش زبان طبیعی، پردازش دقیق تصاویر، تولید محتوای هوشمندانه برای افزایش بازدید و ... از جمله خدماتی است که هوش مصنوعی با کمک دیتای تولید شده انجام میدهد. هر چه دیتای بیشتری در دسترس باشد ضریب دقت الگوریتمهای هوش مصنوعی هم بالاتر می رود.فریمورک SP-Based یک فریمورک دیتاسنتریک است که با توجه به اهمیت دیتا در دنیای آینده یک گزینه اساسی برای استفاده جهت توسعه سامانه های نرم افزاری میباشد. در دنیای آینده هر سامانه ای که بهتر بتواند دیتاها را جذب، ذخیره و به طور مناسب عرضه کند موفق تر است. جذب سریع و آسان در منبع داده ای متناسب و ارائه سریع حجم بالای دیتای درخواستی در کمترین زمان با کمترین هزینه از مهمترین اهداف این سامانه های هستند. به دلایل زیر فریمورک SP-Based برای این منظور بسیار مناسب است:- امکان متصل کردن الگوریتمهای پیاده سازی شده به تعداد نامحدودی منبع داده ای در بستر وب- امکان دریافت سریع و آسان دیتای تولید شده از دیوایسهای مختلف به آسانی- امکان ارائه خدمات مبتنی بر دیتا به سامانه های دیگر- بهینه سازی هوشمند و دستی الگوریتمها حین اجرا برنامه بدون متوقف آن- بهبود الگویتمها سامانه با کمک هوش مصنوعی به خاطر مجازی بودن کدهانتیجه گیریدر ارزیابی های صورت گرفته کفه ترازو به نفع فریمورک SP-Based سنگینی کرد اما به این معنا نیست که فریمورکهای دیگر کارآمدی ندارند بله رویکرد انتخابی ما طوری بوده که این مزایا را به وجود آورده است. البته توسعه دهندگانی هستند که بسته به عادت و توانایی که دارند بشدت طرفدار رویکرد شی گرایی هستند قطعا به این افراد توصیه نمیشود سراغ فریمورک SP-Basedبیایند.برخی از توسعه دهندگان هم هستند که توانایی های فریمورک SP-Based را پذیرفته اند اما بنا به دلایلی نمیخواهند بستر کدنویسی خود را براساس این فریمورک بنا کنند که پیشنهاد میشود از کامپوننتهای این فریمورک بسته به نیازشان در هر لایه ای که موردنظرشان هست با مشاوره ما استفاده کنند.برخی نیز کاملا با رویکرد ما موافق هستند. ما این مژده را برای آنها داریم با کمک مستندات و مشاوره دقیق فارغ از اینکه با چه بانک اطلاعاتی کار می کنند و با چه زبانی کد نویسی می کنند می توانند از این فریمورک برای بستر کدنویسی و توسعه برنامه های خود استفاده کنند. مشاوره و مستندات ما اکثر رایگان بوده و در صورتی که توسعه دهنده مکانیزم یا کارکردی خارج از چهارچوبهای تعریف شده بخواهد به صورت منطقی هزینه ای دریافت میشود. mahdi hoshmandi mahdi hoshmandi Tue, 19 Jan 2021 13:26:51 +0330 https://virgool.io/CodeLovers/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%88-%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE%DA%86%D9%87-%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9sp-based-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-%D8%A7%D8%B3%D8%AA%D9%88%D8%B1-%D9%BE%D8%B1%D9%88%D8%B3%DB%8C%D8%AC%D8%B1-knwrirtbivzq 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 ارتباط با دیتابیس مدیریت میشود. اما این روش مشکلاتی مثل عدم بهینه بودن و افزایش کدنویسی دارد که در آینده بیشتر بحث می کنیم.مقایسه کدنویسی اسکیول ad-hoc و استور پروسیجر5- تاریخچه فریمورک SP-Basedاین فریمورک حاصل حدود 22 سال تجربه بنده است. با تجربه ای که در کار با نسلهای مختلف داشتم مهمترین هدفم را روی حداقل کردن کدنویسی توام با حداقل کردن پیچیدگی گذاشتم. راه اندازی یک هندلر واحد و عام برای پاسخگویی به درخواستهای کلاینت که بتواند با دسته بندی آنها بهترین پاسخ را ارائه دهد. در زیر خلاصه ای از گذشته این فریمورک بیان شده است.تاریخچه توسعه فریمورک SP-Based6- فریمورک SP-Basedباور اینکه سامانه ای که مبتنی بر SP کار کند و توسعه اش آسانتر باشد سخت است. مشکل اینجاست که دوستان همه منطق را میخواهند به داخل SP منطق کنند در صورتی که حتما باید حداقل منطق به آن وارد بشود یعنی مغز دسترسی به دیتا نه اینکه مواردی مثل اعتبارسنجیها، تغییر فرمتها و ... در آن پیاده سازی شود.مورد ترسناک بعدی در رابطه با SP در هم تنیده شدن SP با باقی منطق است در صورتی که ما عقیده داریم نباید حتی یک خط کد اسکریپت داخل لایه میانی باشد از طرف دیگر هم عقیده داریم هر کدی که در خارج از SP قابل هندل هست نیابد وارد SP شود این جدا کردن انواع منطق ها باعث سهلوت در مدیریت کد می شود.فریمورک SP-Based یک فریمورک full stack مبتنی بر SP است که در هر سه لایه کلاینت، وب سرور و دیتابیس دارای استانداردها وکدهای پایه ای است. این فریمورک مکانیزم ساده و کارآمدی برای پیاده سازی پروژه ها دارد. اصل اساسی در این فریمورک پیاده سازی تنها آن چیزی که نیاز است، یعنی دستورات SQL که روی داده ها اثر می گذارند. بنابراین توسعه دهندگان باید درک درستی از مقاهیم SQL نویسی داشته باشند. شرطها و حلقه های موردنیاز در کوئری ها و SP پیاده سازی شده و برنامه نویسی در لایه میانی تقریبا حذف میشود. این فریمورک در توسعه و انتقال یک سامانه دیگر قابلیت انطباق خوبی داشته و باعث مهاجرت راحتر و جا انداختن سریعتر سامانه جدید میشود.بسیاری از عملیاتها برای اجرای درخواستها به صورت خودکار انجام می شود. پیاده سازی عملیاتها قالبا در SP طبق استانداردها و با کمک محیط توسعه تحت وب انجام میشود.این فرآیند باعث تسریع در پیاده سازی عملیاتها شده و کمترین پیچیدگی و لایه بندی را در مسیر اجرای درخواستها ایجاد میکند. همچنین با کمک محیط توسعه ای که در اختیار ذینفعان پروژه می گذارد ارتباط و دسترسی آنها را بدرستی مدیریت میکند تا هر چه سریعتر و ساده تر پروژه توسعه و پشتیبانی گردد.معماری SP-Based ترکیبی از معماری‌های مطرح است که اکثر مزایای آنها را جذب و اکثر معایب آنها را رفع کرده است، در معماری لایه‌ای جذب مزیت جدا بودن کدها و رفع مشکل کدهای انبوه و تکراری،از معماری رویدادگرا جذب ایجاد صف برای دسته بندی عملیاتها و رفع مشکل کانالهای متعدد هندل رویدادها، از میکروسرویس و میکروکرنل جذب هسته کوچک و رفع مشکل وابستگی اجزاء به هسته را را انجام داده است. mahdi hoshmandi mahdi hoshmandi Wed, 13 Jan 2021 10:38:22 +0330 https://virgool.io/@iranerpgroup/%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-%D8%A7%D8%B3%D8%AA%D9%88%D8%B1-%D9%BE%D8%B1%D9%88%D8%B3%DB%8C%D8%AC%D8%B1stored-procedure-based-nj07osendlx2 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 در مرورگر بعد از دریافت نتیجه اجرا می‌شود. به طور کلی نتیجه برگشتی شامل دو دسته است دسته اول ساده و عموما عددی است که عدم اجرای درخواست بخاطر عدم دسترسی یا بروز خطا و نتیجه اجرای موفق را مشخص می کند. دسته دوم شامل رشته است است که توسط توابع مرتبط با عملیات پردازش شده و نتیجه در مرورگر منعکس می‌شود. در شکلهای زیر می توان جزئیات مکانیزم این معماری را برای تعامل با کلاینتها مشاهده نمایید:مکانیزم و فرآیند اجرای درخوستها در معماری مبتنی بر استور پروسیجر SP-Basedنحوه هندل کردن عملیاتهای FCRDE در کلاینت با jQuery4- مزایای فریمورک SP-Based1- حداقل کدنویسی: این فریمورک دارای کمترین کد خاص منظوره است، بنابراین در لایه 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 دسترسی داشته باشیم.مهترین مزایای فریمورک SP-Based5- چالشها و فرصتهای استفاده از 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 است چون بدون نیاز به کامپایل سریعا تغییرات اعمال می شود. بنابراین برنامه های پیچیده ای که دائم بایستی بروزرسانی شوند با کمک این معماری می توانند خیلی راحتر و سریعتر نسخه های جدید و اصلاحات را ارائه دهند. از آنجا که منطق کسب و کار در این فریمورک کاملا در استور پروسیجرهاست حتی تعیین ویو سامانه در استور پروسیجر وجود داره بنابراین کمتر نیاز به ایجاد تغییرات در لایه میانی و کامپایل و پاپلیش هست بنابراین یک جریان دائمی از توسعه رخ میده.دوستان عزیز منتظر ارسال نظرات و ارزیابی فنی تون هستم mahdi hoshmandi mahdi hoshmandi Wed, 07 Oct 2020 11:07:43 +0330