وحید نصیری وحید نصیری
نظرات مطالب
آشنایی با NuGet - قسمت اول
سلام؛ من با قسمت نظرات سایت شما مشکلی نداشتم. الان با دو مرورگر مختلف بررسی کردم و به خوبی دیسکاس نمایش داده میشه.
ضمنا دیسکاس زبان فارسی رو هم اضافه کرده که می‌تونید فعالش کنید
Admin --- Settings --- General --- Language --- Persian
‫۱۳ سال و ۷ ماه قبل، دوشنبه ۲۲ فروردین ۱۳۹۰، ساعت ۲۳:۵۶
آرمان فرقانی آرمان فرقانی
نظرات مطالب
مفاهیم برنامه نویسی ـ مروری بر پروپرتی‌ها
ضمن تشکر از پیگیری و پیشنهادهای حضرتعالی و پوزش به جهت طولانی شدن فاصله زمانی ارائه مطالب در مورد پیشنهادهای ارزشمندی که فرمودید باید چند نکته را عرض کنم.
تا حد زیادی معمولاً سعی کردم این موارد محقق بشه. مثلا در مورد همان اکسسور و بیشتر مفاهیم و اصطلاحات مهم، معادل انگلیسی آورده شده است. اصولاً ترجمه برخی مفاهیم را مناسب نمی‌دانم و از طرفی آوردن تعداد زیادی واژه انگلیسی در بین واژگان فارسی سبب کاهش زیبایی متن می‌گردد. بنابراین معمولاً کلمات مهم را یک یا چند بار به صورت انگلیسی بیان می‌کنم و سپس با حروف فارسی می‌نویسم مانند اکسسور تا به صورت روان‌تری در متن قابل خواندن باشد.
همچنین در امر آموزش ابتدا سعی می‌کنم یک دید کلی و از بالا به دانشجو یا خواننده منتقل کنم. در این مرحله تنها جزییات مهم که برای درک موضوع و شروع کار عملی مانند انجام یک پروژه کاربردی لازم است بیان می‌شود. چراکه اگر از ابتدا ذهن را با تعداد زیادی جزییات درگیر کنیم ممکن است در موقع خواندن هر بخش خواننده مفاهیم را درک کند اما پس از پایان مطالب نمی‌داند از کجا باید شروع کند و قدرت استفاده از آموخته‌ها را ندارد. به همین جهت سعی می‌شود بر روی مفاهیم غیر کلیدی کمتر در مراحل اولیه بحث شود.
از طرفی سعی می‌کنم مطالب دارای حجم مناسب و مفاهیم پیوسته ای باشند تا قابل درک بوده و خسته کننده نباشند. مثلاً از آنجاییکه در بخش‌های پیشین مقاله‌ای که به زحمت یکی از دوستان در سایت قرار گرفته بود برای نامگذاری معرفی شد، از تکرار قوانین یاد شده در این مطالب به جهت جلوگیری از طولانی‌تر شدن خودداری کردم.
با توجه به کارگاه‌های عملی ای که برای تثبیت مطالب در نظر گرفته خواهد شد، تا حد زیادی روش‌های بهینه برای پیاده سازی مفاهیم گوناگون معرفی خواهد شد.
‫۱۱ سال و ۶ ماه قبل، پنجشنبه ۵ اردیبهشت ۱۳۹۲، ساعت ۰۳:۲۰
وحید نصیری وحید نصیری
مطالب
ASP.NET MVC #3

تهیه پیش‌نیازهای شروع به کار با ASP.NET MVC

در زمان نگارش این مطلب، نگارش نهایی ASP.NET MVC 3 در دسترس است و همچنین نگارش بتای 4 آن نیز قابل دریافت و نصب می‌باشد. بنابراین فعلا اساس را بر مبنای نگارشی قرار خواهیم داد که در محیط کاری قابل استفاده باشد.
ASP.NET MVC 3 پس از ارائه Visual Studio 2010، منتشر شد و VS.NET به صورت پیش فرض به همراه ASP.NET MVC 2 است. ساده‌ترین روش نصب ASP.NET MVC 3 بر روی VS 2010 استفاده از برنامه رایگانی است به نام Web Platform Installer. این برنامه را از این آدرس می‌توان دریافت کرد: http://microsoft.com/web/downloads
پس از دریافت آن حداقل دو راه برای نصب ASP.NET MVC 3 وجود دارد. یا گزینه‌ی نصب ASP.NET MVC 3 Tools Update را انتخاب کنید و یا سرویس پک یک VS 2010 را از طریق این برنامه یا جداگانه (بسته کامل و مستقل) دریافت و نصب نمائید. VS 2010 SP1 نیز به همراه ASP.NET MVC 3 است؛ همچنین IIS Express را که نسخه ساده شده IIS 7.5 مخصوص توسعه دهنده‌ها است، می‌توان با این نگارش یکپارچه کرد.


بنابراین به صورت خلاصه بهترین کار این است که سرویس پک یک VS 2010 را یکبار نصب نمائید. اگر این نصب از طریق برنامه Web Platform Installer باشد، به صورت خودکار IIS Express را هم انتخاب و نصب خواهد کرد. اگر فقط SP1 را به صورت مستقل دریافت کرده‌اید، حاوی IIS Express نیست و باید جداگانه آن‌را دریافت و نصب نمائید (^). البته نصب IIS Express در اینجا یک گزینه اختیاری است و الزامی نیست.



مروری بر ساختار یک پروژه ASP.NET MVC

پس از نصب پیش نیازها، امکان انتخاب یک پروژه وب ASP.NET MVC 3 در VS 2010 میسر خواهد شد:


در اینجا گزینه‌ی ASP.NET MVC 3 Web Application را انتخاب می‌کنیم. در صفحه بعدی که ظاهر می‌شود:


حالت Internet Application به همراه یک سری مدل و کنترلر از پیش نوشته شده جهت مدیریت ورود به سایت و ثبت نام در سایت است و حالت Empty تنها به همراه ساختار پیش فرض پوشه‌های یک پروژه ASP.NET MVC است.
فعلا جهت توضیحات اولیه بیشتر، گزینه‌ی Internet Application و نوع View Engine را هم ASPX انتخاب می‌کنیم. کار View Engine، رندر یک View به شکل HTML و ارائه نهایی اطلاعات آن به کاربر است. این نوع‌های متفاوت هم فقط در Syntax تفاوت دارند (به آن templating language هم گفته می‌شود). نوع ASPX همان Syntax متداول قدیمی ASP.NET را تداعی می‌کند و نوع Razor به صورت اختصاصی برای ASP.NET MVC تهیه شده است.
باید در نظر داشت که گزینه مرجح از نگارش 3 به بعد، Razor است (البته این هم سلیقه‌ای است. اگر هیچکدام از این دو را هم نخواهید استفاده کنید مشکلی نیست! می‌شود کلا آن را عوض کرد). هدفم هم از انتخاب ASPX نمایش یک سری ریزه کاری است که شاید برای برنامه نویس‌های ASP.NET Web forms جالب باشد. این موارد را در حالت انتخاب Razor به این وضوح مشاهده نخواهید کرد و محیط خیلی ساده شده است.


همانطور که ملاحظه می‌کنید این فریم ورک یک سری پوشه پیش فرض را توصیه می‌کند. بدیهی است که ضرورتی ندارد تا پوشه Models یا پوشه Controllers حتما در همین پروژه قرار داشته باشند؛ چون زمانیکه پروژه کامپایل شد، محل این پوشه بندی‌ها آنچنان اهمیتی ندارد.
نکته جالب در این تصویر، فایل Site.Master است. بله، این فایل شبیه به همان فایل master page موجود در ASP.NET Web form است که قالب کلی سایت را به همراه داشته و سایر صفحات، قالب خود را از آن به ارث می‌برند. حتی تگ runat=server هم به وضوح در این فایل، در چندین جای آن قابل مشاهده است. تنها تفاوت آن نداشتن فایل code behind است. asp:ContentPlaceHolder نیز در آن تعریف شده است. خلاصه این محیط جدید به معنای دور ریختن تمام آنچیزی که در Web forms وجود دارد نیست. برای نمونه اگر فایل ChangePassword.aspx موجود در پوشه Account را باز کنید، باز هم همان asp:Content معروف به همراه تگ runat=server قابل مشاهده است. برای مثال این محتوای صفحه Error.aspx پیش فرض آن است:

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
 Inherits="System.Web.Mvc.ViewPage<System.Web.Mvc.HandleErrorInfo>" %>

<asp:Content ID="errorTitle" ContentPlaceHolderID="TitleContent" runat="server">
    Error
</asp:Content>

<asp:Content ID="errorContent" ContentPlaceHolderID="MainContent" runat="server">
    <h2>
        Sorry, an error occurred while processing your request.
    </h2>
</asp:Content>

اگر از قسمت Inherits آن صرفنظر کنیم، «هیچ» تفاوتی با ASP.NET Web forms ندارد؛ علت هم به این بر می‌گردد که موتوری که Web forms و MVC از آن استفاده می‌کنند، یکی است. هر دو بر فراز موتور ASP.NET معنا پیدا خواهند کرد.


قرار دادهای پوشه‌های پیش فرض یک پروژه ASP.NET MVC

  • پوشه Controllers حاوی کلاس‌های کنترلری است که درخواست‌های رسیده را مدیریت می‌کنند.
  • پوشه Models حاوی کلاس‌هایی است که اشیاء تجاری و همچنین کار با اطلاعات را تعریف و مدیریت می‌کنند.
  • در پوشه Views، فایل‌های قالب‌های رابط کاربری که مسئول ارائه خروجی به کاربر هستند قرار می‌گیرند. همچنین مطابق قرارداد دیگری، اگر نام کنترلر ما مثلا ProductController باشد (با توجه به اینکه نام کلاس آن هم مطابق قرارداد، مختوم به کلمه Controller است)، فایل‌های Viewهای مرتبط با آن در پوشه Views/Product قرار خواهند گرفت.
  • در پوشه Scripts،‌ فایل‌های جاوا اسکریپت مورد استفاده در سایت قرار خواهند گرفت.
  • پوشه Content محل قرارگیری فایل‌های CSS و تصاویر است.
  • پوشه App_Data جایی است که فایل‌هایی با قابلیت read/write در آن قرار می‌گیرند (و باید دقت داشت که فقط همینجا هم باید قرار گیرند و گرنه این نوشتن‌ها در مکان‌های متفرقه، ممکن است سبب ری استارت شدن برنامه شوند:(^)).

‫۱۲ سال و ۸ ماه قبل، یکشنبه ۶ فروردین ۱۳۹۱، ساعت ۲۱:۰۰
وحید نصیری وحید نصیری
مطالب
استفاده از واژه‌نامه آنلاین babylon در فایرفاکس

مطلبی را امروز در حین جستجو در سایت اسکریپت‌های گریس مانکی دیدم که محض اطلاعات عمومی بد نیست :)

ابتدا گریس مانکی را نصب کنید :)
https://addons.mozilla.org/en-US/firefox/addon/748
یکبار فایرفاکس را ببندید و باز کنید.
اکنون به آدرس زیر رفته و بر روی دکمه install this script در بالای صفحه کلیک کنید:
http://userscripts.org/scripts/show/9671
بعد از نصب آن، به آدرس زیر مراجعه کنید و همین عملیات را تکرار کنید یعنی install this script
http://userscripts.org/scripts/show/36230
خوب، الان دکمه F4 را فشار دهید. یک صفحه مشکی در پائین صفحه باز خواهد شد. (با فشردن مجدد F4 حذف خواهد شد)
تذکر: اگر با فشردن دکمه F4 تغییری را مشاهده نکردید، یکبار فایرفاکس را ببندید و باز کنید تا اسکریپت‌ها کاملا بارگذاری شوند.
بر روی babylon.persian کلیک کنید تا زرد شود (فعال شود)
اکنون بر روی هر کلمه‌ای در صفحه دوبار کلیک کنید تا انتخاب شود، بلافاصله معنای فارسی آنرا در پائین صفحه خواهید دید.

شایان ذکر است که نیازی به نصب babylon نیست و مستقل عمل می‌کند.

نکته: برای زیاد کردن ارتفاع آن بر روی فلش به سمت بالا کلیک کنید، ماوس را نگه داشته و به سمت بالا حرکت دهید (یا برعکس به سمت پائین)




اسکریپت‌های جالبی را با گریس مانکی بر روی فایرفاکس اجرا می‌کنند. (اگر لینک‌های سایت رو پیگیری کرده باشید تشخیص سالم بودن لینک‌های رپید شیر در یک صفحه واقعا کارآمد بود و نمونه‌های بی‌شماری که در سایت اسکریپت‌های آن می‌توانید پیدا کنید یا از آنها ایده بگیرید)

‫۱۵ سال و ۱۲ ماه قبل، یکشنبه ۲۶ آبان ۱۳۸۷، ساعت ۱۹:۴۹
وحید نصیری وحید نصیری
مطالب دوره‌ها
کار با RavenDB از طریق REST API آن
در این قسمت قصد داریم برخلاف رویه معمول کار با RavenDB که از طریق کتابخانه‌های کلاینت آن انجام می‌شود، با استفاده از REST API آن، ساز و کار درونی آن‌را بیشتر بررسی کنیم.


REST چیست؟

برای درک ساختار پشت صحنه RavenDB نیاز است با مفهوم REST آشنا باشیم؛ زیرا سرور این بانک اطلاعاتی، خود را به صورت یک RESTful web service در اختیار مصرف کنندگان قرار می‌دهد.
REST مخفف representational state transfer است و این روزها هر زمانیکه صحبت از آن به میان می‌آید منظور یک RESTful web service است که با استفاده از تعدادی HTTP Verb استاندارد می‌توان با آن کار کرد؛ مانند GET، POST، PUT و DELETE. با استفاده از GET‌، یک منبع ذخیره شده بازگشت داده می‌شود. با استفاده از فعل PUT، اطلاعاتی به منابع موجود اضافه و یا جایگزین می‌شوند. POST نیز مانند PUT است با این تفاوت که نوع اطلاعات ارسالی آن اهمیتی نداشته و تفسیر آن به سرور واگذار می‌شود. از DELETE نیز برای حذف یک منبع استفاده می‌گردد.


چند مثال
فرض کنید REST API برنامه‌ای از طریق آدرس http://myapp.com/api/questions در اختیار شما قرار گرفته است. در این آدرس، به questions منابع یا Resource گفته می‌شود. اگر دستور GET پروتکل HTTP بر روی این آدرس اجرا شود، انتظار ما این است که لیست تمام سؤالات بازگشت داده شود و اگر از دستور POST استفاده شود، باید یک سؤال جدید به مجموعه منابع موجود اضافه گردد.
اکنون آدرس http://myapp.com/api/questions/1 را درنظر بگیرید. در اینجا عدد یک معادل Id اولین سؤال ثبت شده است. بر اساس این آدرس خاص، اینبار اگر دستور GET صادر شود، تنها اطلاعات سؤال یک بازگشت داده خواهد شد و یا اگر از دستور PUT استفاده شود، اطلاعات سؤال یک با مقدار جدید ارسالی جایگزین می‌شود و یا با فراخوانی دستور DELETE، سؤال شماره یک حذف خواهد گردید.


کار با دستور GET

در ادامه، به مثال قسمت قبل مراجعه کرده و تنها سرور RavenDB را اجرا نمائید (برنامه Raven.Server.exe)، تا در ادامه بتوانیم دستورات HTTP را بر روی آن امتحان کنیم. همچنین نیاز به برنامه معروف فیدلر نیز خواهیم داشت. از این برنامه برای ساخت دستورات HTTP استفاده خواهد شد.
پس از دریافت و نصب فیدلر، برگه Composer آن‌را گشوده و http://localhost:8080/docs/questions/1 را در حالت GET اجرا کنید:


در این حالت دستور بر روی بانک اطلاعاتی اجرا شده و خروجی را در برگه Inspectors آن می‌توان مشاهده کرد:



به علاوه در اینجا یک سری هدر اضافی (یا متادیتا) را هم می‌توان مشاهده کرد که RavenDB جهت سهولت کار کلاینت خود ارسال کرده است:


یک نکته: اگر آدرس http://localhost:8080/docs/questions را اجرا کنید، به معنای درخواست دریافت تمام سؤالات است. اما RavenDB به صورت پیش فرض طوری طراحی شده‌است که تمام اطلاعات را بازگشت ندهد و شعار آن Safe by default است. به این ترتیب مشکلات مصرف حافظه بیش از حد، پیش از بکارگیری یک سیستم در محیط کاری واقعی، توسط برنامه نویس یافت شده و مجبور خواهد شد تا برای نمایش تعداد زیادی رکورد، حتما صفحه بندی اطلاعات را پیاده سازی کرده و هربار تعداد معقولی از رکوردها را واکشی نماید.


کار با دستور PUT

اینبار نوع دستور را به PUT و آدرس را به http://localhost:8080/docs/questions/1 تنظیم می‌کنیم. همچنین در قسمت Request body، مقداری را که قرار است در سؤال یک درج شود، با فرمت JSON وارد می‌کنیم.
برای آزمایش صحت عملکرد آن، مرحله کار با دستور GET را یکبار دیگر تکرار نمائید:


همانطور که مشاهده می‌کنید، تغییر ما در عنوان سؤال یک، با موفقیت اعمال شده است.


کار با دستور POST

در حین کار با دستور PUT، نیاز است حتما Id سؤال مورد نظر برای به روز رسانی (و یا حتی ایجاد نمونه جدید، در صورت عدم وجود) ذکر شود. اگر نیاز است اطلاعاتی به سیستم اضافه شوند و Id آن توسط RavenDB انتساب داده شود، بجای دستور PUT از دستور POST استفاده خواهیم کرد.


مطابق تصویر، اطلاعات شیء مدنظر را با فرمت JSON به آدرس http://localhost:8080/docs/ ارسال خواهیم کرد. در این حالت اگر به برگه‌ی Inspectors مراجعه نمائیم، یک چنین خروجی JSON ایی دریافت می‌گردد:


Key در اینجا شماره منحصربفرد سند ایجاد شده است و برای دریافت آن تنها کافی است که دستور GET را بر روی آدرس زیر که نمایانگر Key دریافتی است، اجرا کنیم:
http://localhost:8080/docs/e0a92054-9003-4dda-84e2-93e83b359102


کار با دستور DELETE

برای حذف یک سند تنها کافی است آدرس آن‌را وارد کرده و نوع دستور را بر روی Delete قرار دهیم. برای مثال اگر دستور Delete را بر روی آدرس فوق که به همراه Id تولید شده توسط RavenDB است اجرا کنیم، بلافاصله سند از بانک اطلاعاتی حذف خواهد شد.


بازگشت چندین سند از بانک اطلاعاتی RavenDB

برای نمونه، در فراخوانی‌های Ajaxایی نیاز است چندین رکورد با هم بازگشت داده شوند. برای این منظور باید یک درخواست Post ویژه را مهیا کرد:



در اینجا آدرس ارسال اطلاعات، آدرس خاص http://localhost:8080/queries است. اطلاعات ارسالی به آن، آرایه‌ای از Idهای اسنادی است که به اطلاعات آن‌ها نیاز داریم.


بنابراین برای کار با RavenDB در برنامه‌های وب و خصوصا کدهای سمت کلاینت آن، نیازی به کلاینت یا کتابخانه ویژه‌ای نیست و تنها کافی است یک درخواست Ajax از نوع post را به آدرس کوئری‌های سرور RavenDB ارسال کنیم تا نتیجه نهایی را به شکل JSON دریافت نمائیم.
‫۱۱ سال و ۲ ماه قبل، پنجشنبه ۱۴ شهریور ۱۳۹۲، ساعت ۱۸:۴۲
محمد حیدری محمد حیدری
مطالب
معماری وب گرا (سبکی از سرویس گرایی)
در ابتدای مقاله، پیش از آن که وارد بحث معماری وب گرا بشوم، یک سوال را مطرح میکنم که شاید برای شما هم جالب باشد. آن سوال اینست : آیا SOA پاسخی برای همه چیز در 
حوزه معماری است؟ شاید اینطور نباشد. به ترکیب زیر دقت کنید :
WOA  / SOA + WWW + REST
ترکیب فوق ما را چند قدم جلوتر برده و کاستی‌های سرویس گرایی را پر می‌کند و ما را یاری می‌کند تا اپلیکیشن‌های کامل end-to-end بسازیم.

اگر چه مفهوم WOA شاید چندان فراگیر نباشد، ولی بسیاری از آنچه تاکنون در سطح اینترنت می‌بینیم شالوده همین تفکر وب گرایی است.
معماری وب گرا یا Web-Oriented Architecture در 2006 توسط  Nick Gall از گروه Gartner ابداع شده است. 
معماری وب گرا یک سبک معماری نرم افزاری است که معماری سرویس گرا (Service-Oriented Architecture) را در راستای اپلیکیشن‌های تحت وب گسترش می‌دهد. 
معماری وب گرا در اصل توسط بسیاری از شبکه‌های اجتماعی و وب سایت‌های شخصی ساخته شده است.
تعریف رسمی Gartner از معماری وب گرا چنین است :
 “معماری وب گرا یا Web-Oriented Architecture سبکی معمارگونه از معماری سرویس گرا یا همان Service-Oriented Architecture می‌باشد که به یکپارچگی سیستم‌ها و کاربران از طریق ابررسانه‌های مرتبط با هم در سطح جهانی بر اساس معماری وب می‌پردازد.
 این نوع معماری بر تمامی اینترفیس‌ها (رابط کاربری و  رابط کاربردی برنامه نویسی) به منظور دستیابی به تاثیرات شبکه‌ی جهانی از طریق پنج عنصر رابط اساسی ذیل تاکید دارد :
  • شناسایی منابع
  • بکارگیری منابع از طریق نمایش آنها (منابع وب)
  • پیام‌های خودتوصیفی
  • ابررسانه بعنوان قلب تپنده موقعیت برنامه
  • درگیر نکردن برنامه “
Nick Gall همچنین فرمولی را برای تعریف معماری وب گرا (WOA) ارائه داده است که بدین شکل است:
WOA = SOA + WWW + REST
Dion Hinchcliffe مدعی است که معماری وب گرا چنین است: 

“مجموعه‌ای از هسته پروتکل‌های وب مانند HTTP, XML است و اینکه تنها تفاوت معماری سرویس گرای سنتی و مفاهیم معماری وب گرا اینست که WOA از REST حمایت می‌کند. REST متدی به طور فزاینده محبوب ، قدرتمند و ساده به منظور اعمال نفوذ پروتکل انتقال ابر متن HTTP بعنوان یک وب سرویس در چارچوب حقوق خودش است.“

پشته‌ی معماری وب گرا WOA شامل چنین مواردی است :
  • توزیع (HTTP , Feeds)
  • ترکیب (Hypermedia , Mashups)
  • امنیت (Open ID, SSL)
  • قابلیت انتقال داده (XML,RDF)
  • قابلیت نمایش داده (ATOM, JSON)
  • متدهای انتقال (REST, HTTP, Bit Torrent)
بطور کل باید گفت WOA هر چیزی است که در اینترنت وجود دارد و هر چیزی که بر مبنای REST می‌باشد والبته سرویس گراست. در کلامی گویا باید گفت امروزه معماری وب گرا پراستفاده‌ترین نوع معماری در جهان تا به امروز بوده است. طبق پیش بینی Gartner در 2014 سبک معماری وب گرای (مبتنی بر REST) در 80% سازمان هایی که سرویس گرایی را دنبال می‌کنند فراگیر خواهد شد. واقعا صحت یا عدم صحت تحقق این پیش بینی Gartner شاید مهم نباشد ؛ چرا که هر کسی می‌بایست WOA را بشناسد.
اما REST چیست ؟ Representational State Transfer سبکی از معماری نرم افزار برای سیستم‌های ابررسانه توزیع شده مانند شبکه جهانی وب است (منبع : ویکی پدیا). با هم اصول REST را مرور کنیم:
  • هر چیزی یک منبع است.
  • هر منبعی یک تمثیل دارد.
  • هر منبعی یک نام بخصوص دارد.
  • انتقال موقعیت نیازمند کشف و شهود (Discovery) است.
  • پروتکل شبکه پایه WOA می‌باشد
بطور خلاصه WOA را بررسی می‌کنیم :
  • اطلاعات در قالب منابع (Resources) نمایش می‌یابند.
  • منابع توسط URI‌ها شناخته می‌شوند.
  • منابع از طریق HTTP اداره می‌شوند.
  • معاهدات به صورت ضمنی در نمایش منابع می‌باشند.
  • رابط‌ها بطور کلی عام هستند.
معماری وب گرای سازمانی
معماری وب گرای سازمانی یا Enterprise Web Oriented Architecture (EWOA) یکی از زیر سبک‌های SOA می‌باشد. EWOA مجموعه ای از عناصر، اصول و فرآیندهای معماری مبتنی بر وب می‌باشد. وب سایت‌ها و برنامه‌های کاربردی جدید مانند Google AdSense, Wikipedia و دیگر سرویس‌های RESTful از WOA استفاده می‌کنند.
مثال حال حاضر WOA را می‌توان Google’s Open Social  یا MindTouch دانست. در حال حاضر Mobile API بنایی اساسی بر تمرکز در استفاده از تکنولوژی WOA را دارند. ساخت چنین سرویس هایی با استفاده از پروتکل‌های ساده شده وب نظیر Rest , JSON بیش از پیش آسان شده است. این پروتکل‌ها برای توسعه دهندگان وب بسیار راحت‌تر است چرا که CPU و پهنای باند کمتری را طلب می‌کنند. این پروتکل‌ها بیشتر بخاطر شبکه‌های اجتماعی بزرگ نظیر فیس بوک ، آمازون ، توییتر و … شناخته شده‌اند.
MindTouch هم یک شرکت اوپن سورس و یک سکوی مستندسازی استراتژیک و نوعی جدید از ECM می‌باشد. از جمله پروژه‌هایی که ارایه کرده‌است می‌توان به موارد ذیل اشاره کرد :
DReAM
SGML Reader
MindTouch Core/2010
در ادامه، بکارگیری REST را در قالب شبکه جهانی وب (W3) در قالب جدول زیر با دیدگاه مقایسه‌ای با تلفیق در وب بررسی می‌کنیم:
{بنده می‌گویم} REST بدون WWW بی معناست. REST با Web است که تکمیل می‌شود و معنا پیدا می‌کند.
بررسی مزایای WOA
  • ساده سازی توسعه پذیری، مقیاس پذیری
  • کاهش زمان توسعه ویژگی‌های جدید
  • کاهش زمان مهندسی مورد نیاز برای یکپارچه سازی
  • سازنده فرصت‌هایی جدید برای mash-ups و دیگر داستان‌های غیرقابل پیش بینی کاربری
  • اما وضعیت ارتباطی کلاینت‌ها و سرورها در WOA چگونه است ؟
  • سرویس‌ها وابسته به دیگر سرویس‌ها هستند.
  • ارتباطات از طریق HTTP صورت می‌گیرد.
  • کلاینت‌ها حکم منبع و سرویس دهی به دیگر کلاینت‌ها را دارند.
  • مقیاس پذیری ، توسعه پذیری == اتصالات داخی 


بعنوان مثال می‌توان با ترکیب تصاویر و آدرس‌های مختلف دانشگاه‌های تهران، یک map Mashup درست کرد.


برای Photo Mashup ابزار Color Picker هم هست که امکان جستجوی تصاویر را بر اساس رنگ فراهم می‌کند و از سرویس اشتراک گذاری عکس Flickr استفاده می‌کند که در این آدرس قابل استفاده است.

معماری Mashup هم مثل معماری MVC (البته با تفاوت‌های فاحش) سه لایه‌ای است :


لایه نمایش / تعامل کاربر (همان رابط کاربری است)

تکنولوژی‌ها : HTML/XHTML, CSS, Javascript, Asynchronous JS and Xml (Ajax).

وب سرویس‌ها : عملکرد محصول از طریق سرویس‌های API هم قابل دسترسی است

تکنولوژی‌ها : XMLHTTPRequest, XML-RPC, JSON-RPC, SOAP, REST

داده : فراهم آوردن امکان ارسال ، مرتب سازی و دریافت داده

تکنولوژی‌ها : XML , JSON , KML

از نظر معماری  Mashup  دارای 2 سبک است : الف) مبتنی بر وب – ب) مبتنی بر سرور


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

شاید برای شما سوال پیش بیاید که ما در معماری وب گرا بحث می‌کردیم، اصلا چرا وارد مفهوم Mashup شدیم؟


به‌عبارت فنی‌تر چرا معماری وب گرا (WOA) برای Mashups اهمیت دارد ؟

 پاسخ یک کلمه است : REST . همانطور که بالاتر نیز اشاره کردم، Mashup از REST بهره می‌برد. به منظور افزایش اطلاعات در رابطه با REST باید گفت Roy Fielding آنرا بنیان نهاده‌است. میخواهید او را بهتر معرفی کنم؟ وی یکی از خالقان HTTP است و مگر می‌توان وب را بدون HTTP فرض کرد که مهمترین پروتکل انتقال ابر متن در جهان و پروتکل زیربنایی وب است؟! 

REST به خوبی با معماری اینترنت عجین شده است! بپرسید چرا؟ چون پروتکل اصلی اینترنت HTTP است و هر دوی این‌ها از یک ذهن نشات گرفته و او کسی نیست جز Roy Fielding. اما باید بگویم REST یک استاندارد نیست؛ با وجود سادگی بسیار زیاد، تنها یک سبک استفاده از HTTP است.


REST همچنین از متدهای اختصاصی HTTP نظیر GET, PUT , POST , DELETE در بالای یک URL استفاده می‌کند تا نشان دهد چه رویدادی رخ می‌دهد.


در پایان گفته‌ها در رابطه با REST باید بگویم ATOM همان REST است. منظورم از ATOM ویرایشگر معروف متنی نیست که برای نوشتن کدهای برنامه نویسی استفاده قرار می‌گیرد؛ آنرا غالبا به شکل Atom می‌نویسند چرا که مخفف چند کلمه نیست و یک کلمه خاص است  اما ATOM یک استاندارد وب به زبان XML است که برای خوراک وب بعنوان جایگزینی برای RSS استفاده می‌شود. ATOM را با AtomPub یا APP اشتباه نگیرید؛ چرا که APP پروتکل انتشاری است مبتنی بر پروتکل انتقال ابرمتن (HTTP) و برای به روزرسانی محتوی وب مورد استفاده قرار می‌گیرد.

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

فرمول جالبی هم برای تعریف وب ارائه شده‌است که با هم می‌بینیم :


HTTP + URIs = Web


ظرافت فرمول بالا به اهمیت پروتکل زیربنایی وب یعنی HTTP اشاره دارد. URI هم مجموعه‌ای از رشته‌هاست که برای شناسایی یک منبع خاص تحت وب به کار می‌روند. در شکل زیر رابطه بین URI , URN , URL را بررسی می‌کنیم. URI تشکیل شده‌است از URL و URN .URL متد دسترسی به منبع را مشخص می‌کند، در حالیکه URN تنها مشخص کننده نام منبع می‌باشد و هیچگونه روشی را برای دسترسی به ما ارائه نمی‌دهد. بعنوان مثال یک شماره ISBN کتاب، یک نوع URN است. 




‫۶ سال و ۱۱ ماه قبل، چهارشنبه ۲۴ آبان ۱۳۹۶، ساعت ۱۴:۵۵
حامد یادآفرین حامد یادآفرین
نظرات مطالب
بومی سازی تاریخ و اعداد در جاوا اسکریپت در سال 2020
با سلام؛ خروجی تاریخ رو گرفتم اما درصورتی که اعداد تاریخ خروجی با کاراکتر عددی انگلیسی باشد چه روشی را پیشنهاد می‌کنید. آیا باید از تابع NumberFormat استفاده کرد. چگونه؟
‫۴ سال و ۶ ماه قبل، یکشنبه ۱۰ فروردین ۱۳۹۹، ساعت ۱۹:۰۵