ابزار سایت

معرفی_معماری_موتوشاب

فصل 2- معرفی معماری موتوشاب

توسعه و بهبود موتوشاب نیازمند درک مناسبی از معماری آن است. کلاس‌های موجود در موتوشاب را از منظر هدف ‌می‌توان به دو دسته تقسیم نمود. دسته اول کلاس‌ها و توابعی‌ هستند که هدفشان فراهم‌سازی یک زیرساخت توسعه در موتوشاب است و دسته دوم با هدف پیاده‌سازی موارد کاربرد1 سامانه مبتنی بر همین زیرساخت توسعه ایجاد شده‌اند. زیرساخت توسعه شامل تمامی کلاس‌هایی است که قابلیت‌های مربوط به هسته سامانه را تشکیل می‌‏دهند. هسته این زیرساخت در بسته نرم‌‏افزاری ow_core قرار داده شده است. قابل توجه است که این زیرساخت توسعه، در واقع یک چارچوب توسعه مبتنی بر وب، مشابه آن‌چه که در PHPCake 2 و Symfony3 وجود دارد، ارائه کرده‌ است.

کلاس‌های موجود در ow_core به همه مؤلفه‌های دیگر خدمات ارائه می‌کنند؛ اما می‌بایست تصریح شود که اگرچه قابلیت‌هایی همچون امکان درج پست، نظر4، مدیریت کاربران و حتی مدل‌داده‌ کاربر قابلیت‌های هسته‌ای سامانه به نظر می‌رسند، اما در ow_core قرار ندارند؛ بلکه همان‌طور که در ادامه نیز به صورت مشروح بیان خواهد شد، این موجودیت‌ها، تشکیل‌دهنده قلمرو مسئله5 و عملیات مرتبط با آن‌ها در بسته نرم‏‌افزاری ow_system_plugins هستند. این بسته نرم‌افزاری شامل دو زیربسته نرم‌افزاری admin و base است:

  • بسته نرم‌افزاری admin حاوی تمامی قابلیت‌های مدیریت سامانه مانند مدیریت کاربران، مدیریت داشبورد‌ها، ویرایش زبان‌های سامانه و منوی مدیریت است.
  • بسته نرم‌افزاری base شامل تمامی قابلیت‌های پایه‌ای سامانه مانند نظر، آواتار، پست، نمایه کاربر و تمامی عملیات مرتبط است.

توجه شود که در بسته نرم‌افزاری ow_core بستر‌های توسعه فراهم شده است و در بسته‌های نرم‌افزاری‌ base و admin واقع در ow_system_plugins تمامی قابلیت‌های سامانه پیاده‌سازی شده است. بنابر آنچه تا‌کنون بیان شد، به طور کلی ساختار موتوشاب را می‌توان در شکل 1 مشاهده کرد. با توجه به شکل، ow_system_plugins و ow_plugins بر روی ox_core بنا نهاده شده‌اند. همچنین تمامی بسته‌های نرم‌افزاری‌ از ow_utilities و ow_libraries استفاده می‌کنند. برای مطالعه بیشتر در خصوص معماری Oxwall به سند «معماری راهکار جامع» مراجعه شود.

شکل 1: مؤلفه‌های اصلی موتور شبکه اجتماعی موتوشاب

بر اساس شکل 1، بسته‌ نرم‌افزاری ow_core بستری برای توسعه کل سامانه ایجاد کرده است و به پیاده‌سازی سناریو‌های قلمرو مسئله و مدل‌های داده‌ای مرتبط با‌ ‌‌آن‌ها نپرداخته است. چنین رویکرد معمارانه مشابه الگوی معماری Microkernel است. در این الگو قابلیت‌های هسته‌ای یک سامانه که تمامی دیگر قابلیت‌ها مبتنی بر آن‌ها پیاده‌سازی می‌شوند در یک هسته جمع‌آوری شده و واسط‌های مناسب برای تعامل با این هسته تعیین می‌گردد. به طور کلی، تمامی بسته‌های نرم‌افزاری در موتوشاب کنار یک‌دیگر یک هدف مشترک را دنبال می‌کنند و آن فراهم‌سازی بستری به جهت توسعه افزونه‌‏های مورد نیاز یک شبکه اجتماعی کامل است. تأکید می‌شود که تمامی موجودیت‌ها و رفتار‌های قلمرو مسئله نیز از طریق افزونه‌های سامانه‌ای پیاده‌سازی شده‌اند. این بستر مبتنی بر الگوی معماری MVC بنا نهاده شده است که شامل سه لایه می‌شود: لایه مدل داده، لایه کنترل‌کننده و لایه نمایش. هر کدام از این سه لایه وظایف معینی را دارد. در شکل 2 شمای کلی این معماری به تصویر کشیده شده است. در ادامه به شرح هر کدام از لایه‌ها پرداخته شده است.

شکل 2: معماری سه‌لایه موتوشاب مبتنی بر الگوی معماری MVC

1. لایه مدل‌داده

این لایه مسئول نگه‌داری اطلاعات و ذخیره‌سازی و بازیابی آن از پایگاه داده است. به جهت فراهم‌سازی چنین بستری دو موجودیت OW_Entity و OW_BaseDao در هسته موتوشاب در نظر گرفته شده‌اند:

  • OW_Entity: این موجودیت یک کلاس پایه برای تمامی موجودیت‌های سامانه است که می‌بایست در پایگاه داده ذخیره شوند. به عنوان مثال موجودیت پست، کاربر، نظر، آواتار، پسند یک پست و غیره از این دسته موجودیت‌ها هستند که متناظر با هرکدام یک کلاس تعریف می‌‏شود که از OW_Entity ارث‌بری کرده است. کلاس OW_Entity بسیار سبک بوده و درواقع این کلاس صرفا حامل فیلد id بوده که همان کلید اصلی6 متناظر با مدل‌داده است؛ بنابراین کلید اصلی تمامی موجودیت‌های سامانه همان فیلد id خواهد بود. همچنین کلاس OW_Entity تابعی برای استخراج فیلد‌های تغییر کرده یک موجودیت دارد. به ‌غیر از موارد ذکرشده این کلاس هیچ مسئولیت دیگری ندارد و صرفا یک کلاس پایه مشترک برای تمامی موجودیت‌های ذخیره‌شونده در سامانه است. به عنوان مثال در شکل 3 (الف) کلاس موجودیت Post قابل‌مشاهده است.
  • OW_BaseDao: به طور کلی تمامی عملیاتی که بر روی داده‌های یک موجودیت صورت می‌پذیرد از طریق شیء دسترسی به داده7 (DAO) متناظر با آن انجام می‌شود. این الگو در توسعه شیءگرای سامانه‌ها پیش‌تر نیز به طور گسترده مورد استفاده قرار گرفته است. به عنوان مثال توسعه کلاس‌های DAO به ازای هر موجودیت اطلاعاتی در JavaEE یک الگوی استاندارد به حساب می‌آید.

در این کلاس عملیاتی همچون ذخیره شئ، بازیابی مبتنی بر پرسمان، حذف از پایگاه داده و برخی از عملیات تجمیعی صورت می‌پذیرد. در شکل 3 (ب) نمودار کلاس OW_BaseDao به همراه یکی از فرزندان آن؛ یعنی PostDao که برای مدیریت داده‌های موجودیت Post ایجاد شده است، قابل‌مشاهده است.

شکل 3: (الف) نمودار کلاس موجودیت Post به همراه کلاس پایه OW_Entity (ب) نمودار کلاس PostDao به همراه کلاس پایه OW_BaseDao MVC

2. لایه نمایش: این لایه مسئول نمایش اطلاعات موجود در لایه مدل‌داده به کاربر در قالب واسط کاربری است. در موتوشاب این امر توسط قالب‌های smarty محقق شده است. قالب‌های smarty درواقع همان فایل‌های HTML هستند با این تفاوت که داخل آن‌ها یک زبان برنامه‌نویسی خاص ارائه شده توسط smarty قابل استفاده است. این قالب‌ها نوعی موتور قالب PHP هستند که قالب را از کد منبع جدا کرده و بین آن‌ها ارتباط برقرار می‌کنند. با بهره‏‏‌گیری از این زبان میانی لایه ‌کنترل‌کننده که در ادامه توضیح داده شده است تا جای ممکن از لایه نمایش مستقل شده است.

3. لایه کنترل‌کننده: این لایه با دو لایه نمایش و مدل‌داده در تعامل است. لایه کنترل‌کننده جریان داده را به سمت لایه مدل‌داده هدایت می‌کند و هر زمان که نیاز باشد لایه نمایش را به‌روز کرده و یا داده‌های ورودی کاربر را از آن تحویل می‌گیرد. نحوه دسترسی به داده‌ها نیز از طریق استفاده از اشیاء DAO صورت می‌گیرد8. منطق کسب‌وکاری یک مورد کاربرد معمولا داخل کنترل‌کننده‌ها جای ‌می‌گیرد. درنتیجه غالبا در‌هم‌تنیدگی قابل ‌ملاحظه‌ای بین دو لایه کنترل‌کننده و نمایش‌دهنده وجود دارد. در توسعه موتور شبکه اجتماعی موتوشاب، به جهت تحقق لایه کنترل‌کننده و اتصال آن به لایه نمایش‌، از موجودیت‌هایی استفاده شده است که دارای توابع رفتاری بوده و توانایی پردازش9 و به نمایش‌ در‌آمدن خود را دارا هستند. به عنوان مثال یک منو در پایین صفحه، مؤلفه‌ای است که حاوی اطلاعات گزینه‌های منو، URL متناظر با هرکدام از گزینه‌ها و چینش آن‌ها است. همچنین امکان افزودن یا حذف یک گزینه در منو و درنهایت پردازش محتوایش را نیز دارد10. بدین ترتیب الگوی MVC محقق شده است. به عنوان مثالی دیگر می‌توان به «نظر» اشاره کرد. نظر مؤلفه‌ای است که دارای یک محتوا، تعدادی برچسب، کاربری که نظر را ایجاد کرده و تاریخ ایجاد است. درون این مؤلفه منطق‌های گوناگونی ازجمله کنترل سطح دسترسی، طریقه نمایش و غیره وجود دارد. همان‌طور که ذکر شد ارتباط تنگاتنگی بین دو لایه کنترل‌کننده و نمایش‌دهنده وجود دارد. به جهت روشن‌تر شدن سازوکار این دو لایه در ادامه به موجودیت‌های اصلی مرتبط پرداخته می‏شود:

  • OW_Renderable: هر شیء OW_Renderable، قالب11 مختص به خود را دارد. همچنین می‌تواند حاوی یک یا چند فرم نیز باشد که از طریق تابع getForm قابل دست‌یابی است. درنهایت هر OW_Renderable دارای یک تابع render است که قالب مربوطه‌اش را با اطلاعات داخل این موجودیت پردازش می‌کند. به طور دقیق‌تر فرایند پردازش شامل آماده نمایش شدن فایل‏های محتوای المان‏‌ها، تمامی فرم‌های داخل آن‏‌ها و همچنین تمامی اجزای آن المان می‌شود.
  • OW_Component: مؤلفه‌های نمایشی در Oxwall توسط کلاس OW_Component تعریف می‌شوند. کلاس OW_Component فرزند OW_Renderable است. به عنوان مثال BASE_CMP_Menu کلاس پایه تمامی منوهای سامانه است که رفتار‌های یک منو را در خود جای داده است. در انتها این کلاس توانایی پردازش خود را دارد که این توانایی را به علت رابطه فرزندی با OW_Renderable کسب کرده است.
  • OW_ActionController: این کلاس فرزند OW_Renderable است. برای افزودن قابلیت به سامانه (که ممکن است شامل یک یا چند صفحه نیز باشد)، می‌بایست کلاسی را از OW_ActionController ارث‌بری کرده و منطق سمت کارگزار در آن توسعه داده شود. اکثریت قریب به اتفاق منطق‌های کسب‌و‌کاری12 سمت کارگزار در این سامانه، داخل کنترل‌کننده‌ها که همگی فرزند OW_ActionController هستند قرار دارند.

OW_ActionController با هدف پیاده‌سازی یک سناریوی کامل استفاده می‌شود. ممکن است این سناریو شامل یک یا چند صفحه نیز باشد. حال‌آنکه OW_Component بیشتر برای توسعه المان‌های داخل صفحه مانند منوها، دکمه‌ها، پنجره‌های کوچک و غیره کاربرد دارد. شکل 4 نمودار کلاس موجودیت‌های شرح داده‌شده را به تصویر کشیده است. موجودیت ADMIN_CTRL_Abstract در این شکل، فرزند OW_ActionController بوده که والد تمامی کنترل‌کننده‌های متناظر با صفحات مدیریت سامانه در موتوشاب است.

شکل 4: نمودار کلاس موجودیت‌های اصلی واحد‌های نمایشی در Oxwall

اکنون که تمامی موجودیت‌های اصلی و وظایف‌ آن‌ها شرح داده شد رفتار سطح بالای سامانه برای پاسخ‌گویی به یک درخواست در شکل 5 قابل مشاهده است. درخواست ابتدا از index.php آغاز می‌شود. در این فایل ابتدا پیکربندی توسط فراخوانی init.php صورت می‌گیرد. سپس زنجیره فراخوانی آن‌طور که در شکل آمده است رخ می‌دهد. در انتهای این زنجیره کنترل‌کننده مناسب برای پاسخ‌گویی به درخواست است. پس از فراخوانی تابع مناسب کنترل‌کننده نتیجه پردازش شده و سپس به کاربر پاسخ داده می‌شود.

شکل 5: نمودار توالی پاسخ‌گویی به یک درخواست در Oxwalll

در نمودار فوق خط‌هایی که به سمت راست کشیده شده‌اند نشان‌دهنده فراخوانی و خطوطی که به صورت خط‌چین به سمت چپ کشیده شده‌اند بیان‌کننده بازگشت از زیرشاخه‌ها هستند.

1) Use case
4) Comment
5) Problem domain
6) Primary key
7) Data access object
8) این کار توسط الگوی تک‌شیء صورت می‌پذیرد.
9) Render
10) توجه کنید که به جهت ذخیره و بازیابی اطلاعات از لایه مدل داده داخل کنترل‌کننده‌ سرویس گرفته شده است.
11) Template
12) Business logic
معرفی_معماری_موتوشاب.txt · آخرین ویرایش: 2019/01/15 12:45