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

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

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

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

در حوزه کاری ما همیشه نیازمندی‌های جدید باعث پیشرفت، ارتقاء و پیچیده‌تر شدن سیستم‌های سخت افزاری و نرم افزاری می‌شوند. بطور مثال زمانیکه نیاز شد چندین سیستم از داده‌های مشترکی استفاده کنند، در معماری Single Tier قسمت Database از سایر قسمت‌ها جدا شد و در سخت افزار دیگری قرار گرفت. به این صورت این معماری تبدیل به Two Tier شد و سپس برای اینکه تغییرات، کمترین تاثیر را در سیستم ما داشته باشد و با کمترین هزینه به Platform‌های دیگر نیز سرویس بدهی ...

روش سوم: DTO (Data transfer objects) در قسمت‌های قبلی دو روش از روش‌های موجود جهت تبادل داده‌ها بین لایه‌ها، ذکر گردید و علاوه بر این، مزایا و معایب هر کدام از آنها نیز ذکر شد. در این قسمت دو روش دیگر، به همراه مزایا و معایب آنها برشمرده می‌شود. لازم به ذکر است هر کدام از این روش‌ها می‌تواند با توجه به شرایط موجود و نظر طراح نرم افزار، دارای تغییراتی جهت رسیدن به یکسری اهداف و فاکتور‌ها در نرم ...

قسمت اول : تبادل داده‌ها بین لایه ها- قسمت اول روش دوم: Uniform(Entity classes) روش دیگر پاس دادن داده‌ها، روش uniform است. در این روش کلاس‌های Entity ، یک سری کلاس ساده به همراه یکسری Property ‌های Get و Set می‌باشند. این کلاس‌ها شامل هیچ منطق کاری نمی‌باشند. برای مثال کلاس CustomerEntity ...

معماری لایه بندی شده، یک معماری بسیار همه گیر می‌باشد. به این خاطر که به راحتی SOC ، decoupling و قدرت درک کد را بسیار بالا می‌برد. امروزه کمتر برنامه نویس و فعال حوضه‌ی نرم افزاری است که با لایه‌های کلی و وظایف آنها آشنا نباشد ( UI layer آنچه که ما می‌بینیم، middle layer برای مقاصد منطق کاری، data acce ...

در قسمت قبلی مدیریت همزمانی در بروز رسانی‌ها را بررسی کردیم. در این قسمت مرتب سازی (serialization) پراکسی‌ها در سرویس‌های WCF را بررسی خواهیم کرد. مرتب سازی پراکسی‌ها در سرویس‌های WCF فرض کنید یک پراکسی دینامیک (dynamic proxy) از یک کوئری دریافت کرده اید. حال می‌خواهید این پراکسی را در قالب یک آبجکت CLR سریال کنید. هنگامی که آبجکت‌های موجودیت را بصورت POCO-based پیاده سازی می‌کنید، EF بصورت خودکار یک آبجکت دینامیک مشتق شده را در ...

در قسمت قبل رویکرد‌های مختلف برای حذف موجودیت‌های منفصل را بررسی کردیم. در این قسمت مدیریت همزمانی یا Concurrency را بررسی خواهیم کرد. فرض کنید می‌خواهیم مطمئن شویم که موجودیتی که توسط یک کلاینت WCF تغییر کرده است، تنها در صورتی بروز رسانی شود که شناسه (token) همزمانی آن تغییر نکرده باشد. به بیان دیگر شناسه ای که هنگام دریافت موجودیت بدست می‌آید، هنگام بروز رسانی باید مقداری یکسان داشته باشد. مدل زیر را در ...