شیرپوینت و مشکلی به نام توسعه پذیری در طراحی پورتال

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

راهکار نخست توسعه ابزارهای شیرپوینت بر بستر ASP.NET می باشد. ضمن اینکه این روش مزایایی همچون یکپارچگی با ابزارهای آفیس، مجتمع سازی فرآیند با موتور گردش کار، امکان بهره برداری از کتابخانه های ارایه شده در شیرپوینت و قابلیت توسعه پذیری در مقیاس بالا را به ارمغان درآورده اما این امر کماکان با مشکلاتی همراه است.
افزودن کدهای سفارشی سازی شده به سختی امکان پذیر است. در این رابطه ساختار WSP از سوی شیرپوینت ارایه شده است که بایستی از طریق ابزار Visual Studio.Net ترجمه شود.

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

ضمن اینکه در حالت کلی، روال یادگیری زبان های برنامه نویسی اسکریپت نویسی همچون PHP و یا حتی زبان شی گرایی مثل C# به مراتب منحنی پرشتاب تری نسبت به یادگیری ساختار بسته شیرپوینت دارند.
در روش دوم، توسعه دهندگان امکان ایجاد برنامه های کاربردی دات نت را بر بستر شیرپوینت در اختیار خواهند داشت. از جمله مزایای این روش می توان به کاهش هزینه توسعه با توجه به ساده تر بودن مدل برنامه های ASP.NET، سادگی در توسعه و استقرار ،حجم بالای منابع در دسترس و بهره برداری آزاد از کلیه امکانات فریم ورک دات نت می توان اشاره کرد. اما در واقع با این رویه نمی توان به ساختار مجتمع و توسعه پذیر شیرپوینت دست یافت. ضمن اینکه :

• با استفاده از ابزارهای دات نت، تلاشی زیاد جهت دستیابی به استاندارد های شیرپوینت مورد نیاز است
• هیچ کتابخانه و قابلیت توکاری از مجموعه شیرپوینت در اختیار توسعه دهنده وجود ندارد
• دانش بالایی از پایگاه داده جهت توسعه سایت های داده ای شیرپوینت مورد نیاز برنامه نویسان می باشد.

ضمن اینکه بایستی معماری امنیتی برنامه را با شیرپوینت مطابق کرد. متاسفانه شیرپوینت براحتی امکان دسترسی به پایگاه داده خود را فراهم نکرده و به جای آن توابع مدیریت رویه های دسترسی به داده را ارایه کرده است. هر توسعه دهنده به این مسئله اعتراف خواهد کرد که بدون تعامل مستقیم با پایگاه داده ، توسعه و خطایابی برنامه های کاربردی امری کاملا دشوار و پیچیده است.
همانطور که اشاره شد توسعه یک فرم وب در ASP.Net بسیار ساده تر از توسعه یک وب پارت می باشد. راهکار CQWP به منظور توسعه وب پارت ها و جهت واکشی محتوا از منبع یعنی مولفه های محتوایی پایگاه داده در سطح برنامه توسط شیرپوینت ارایه شده است. پیچیدگی در توسعه کنترل های کاربر و مجتمع سازی در وب پارت های شیرپوینت و عدم انعطاف پذیری شیرپوینت جهت جانمایی محتوا در قالب های سفارشی سازی از مشکلات این بخش است. شیرپوینت جهت تعریف ساختار قالب ها از XSL بهره برداری می نماید. هر چند XSL و HTML هر دو براساس SGML پایه گذاری شده اند اما XSL نه تنها سادگی HTML را برای طراحان به همراه نیاورده، بلکه هرگز محبوبیت و رواج آن را نیز کسب نکرده است. ضمن اینکه محدودیت دیگری نیز وجود دارد. ساختار XSL بر اساس ساختار چیدمان جدول بوده و براحتی نمی توان از تکنیک های استایل شیت ها جهت ارتقای کارایی صفحات ، بهره برداری کرد.
ناسازگاری در نسخه ها مشکل شیرپوینت در بخش وب پارت ها است. بگونه ای که وب پارت های تولید شده در نسخه های قبلی در ویرایش های جدید این نرم افزار قابل اجرا نبوده و بایستی تغییرات در کد آنها صورت گیرد.
نهایتا نبایستی فراموش کرد که شیرپوینت محصولی متن باز نیست. و البته هرگز محصولی ساده جهت بومی سازی و سفارشی نبوده است. برای یک سازمان بزرگ روبه توسعه با فرآیندهای کسب و کار پیچیده و نیازهای روزافزون قابلیت توسعه های وسیع یک بعد پنهان قضیه می تواند باشد. هرچند این وضعیت تاکنون در سایر کشورها بدلیل پشتیبانی شرکت تولید کننده مطلوب تر بوده، اما درسازمانهای داخلی این ساز و کار کاملا متفاوت و بغرنج است. آیا بایستی در صورت بروز نیازهای کلیدی منتظر محصولی از یک تولید کننده خارجی بود که هیچ گونه بازخوردی از مشتریان غیررسمی و تحریم شده خود در زمینه توسعه های آتی دریافت نکرده است؟ حداقل در مورد محصولات داخلی و یا بسیاری از نمونه های متن باز می توان دورنمای امیدوارکننده ای از بلوغ قابل انتظار محصول را متصور شد، اما در شیرپوینت نبایستی این چنین انتظاری داشت.

منبع: طراحی سایت هوشمند