اون پروژه پیش فرض Xamarin Forms رو تونستید بیلد کنید؟ یا یه پروژه ساده UWP؟
نظرات مطالب
ASP.NET MVC #19
بله. اسمبلی استاندارد System.Web.dll را باید به آن پروژه اضافه کنید (از منوی پروژه گزینه افزودن ارجاعات).
با سلام.
یک پروژه class library در solution خود دارم. چگونه میشود فضای نام پیش فرض این پروژه و فایلهای درون آنرا براساس $safeprojectname$ تغییر داد.
نظرات مطالب
EF Code First #12
ممنون از جوابتون، تو نگاه به این پروژه بنظرم اومد شاید بشه این تنظیمات رو توی یک پروژه جداگانه نگهداری کرد!
نظرات مطالب
معرفی پروژه Orchard
سپاس
در صورت امکان مقایسه ای بین این پروژه و kooboo که آن هم پروژه cms با asp.net mvc3 هست داشته باشید
پاسخ به بازخوردهای پروژهها
چند پیشنهاد به همراه پروژه
دوست عزیز اگر تمایل داشته باشید میتوانید مواردی که میخواهید در این پروژه لحاظ کنید به من منتقل کنید تا من روی پروژه شما اعمال کنم.
مطالب
SignalR
چند وقتی هست که در کنار بدنه اصلی داتنت فریمورک چندین کتابخونه به صورت متنباز در حال توسعه هستند. این مورد در ASP.NET بیشتر فعاله و مثلا دو کتابخونه SignalR و WebApi توسط خود مایکروسافت توسعه داده میشه.
SignalR همونطور که در سایت بسیار خلاصه و مفید یک صفحهای! خودش توضیح داده شده (^) یک کتابخونه برای توسعه برنامههای وب «زمان واقعی»! (real-time web) است:
Async library for .NET to help build real-time, multi-user interactive web applications.
برنامههای زمان واقعی به صورت خلاصه و ساده بهصورت زیر تعریف میشن (^):
The real-time web is a set of technologies and practices that enable users to receive information as soon as it is published by its authors, rather than requiring that they or their software check a source periodically for updates.
یعنی کاربر سیستم ما بدون نیاز به ارسال درخواستی صریح! برای دریافت آخرین اطلاعات به روز شده در سرور، در برنامه کلاینتش از این تغییرات آگاه بشه. مثلا برنامههایی که برای نمایش نمودارهای آماری دادهها استفاده میشه (بورس، قیمت ارز و طلا و ...) و یا مهمترین مثالش میتونه برنامه «چت» باشه. متاسفانه پروتوکل HTTP مورد استفاده در وب محدودیتهایی برای پیادهسازی این گونه برنامهها داره. روشهای گوناگونی برای پیادهسازی برنامههای زمان واقعی در وب وجود داره که کتابخونه SignalR فعلا از موارد زیر استفاده میکنه:
- تکنولوژی جدید WebSocket (^) که خوشبختانه پشتیبانی کاملی از اون در دات نت 4.5 (چهار نقطه پنج! نه چهار و نیم!) وجود داره. اما تمام مرورگرها و تمام وب سرورها از این تکنولوژی پشتیبانی نمیکنند و تنها برخی نسخههای جدید قابلیت استفاده از آخرین ورژن WebSocket رو دارند که میشه به کروم 16 به بالا و فایرفاکس 11 به بالا و اینترنت اکسپلورر 10 اشاره کرد (برای استفاده از این تکنولوژی در ویندوز نیاز به IIS 8.0 است که متاسفانه فقط در ویندوز 8.0 موجوده):
Chrome 16, Firefox 11 and Internet Explorer 10 are currently the only browsers supporting the latest specification (RFC 6455). - یه روش دیگه Server-sent Events نام داره که دادههای جدید رو به فرم رویدادهای DOM به سمت کلاینت میفرسته(^).
- روش دیگهای که موجوده به Forever Frame معروفه که در این روش یک iframe مخفی درون کد html مسئول تبادل دادههاست. این iframe مخفی بهصورت یک بلاک Chunked (^) به سمت کلاینت فرستاده میشه. این iframe که مسئول رندر دادههای جدید در سمت کلاینت هست ارتباط خودش رو با سرور تا ابد! (برای همین بهش forever میگن) حفظ میکنه. هر وقت رویدادی سمت سرور رخ میده با استفاده از این روش دادهها بهصورت تگهای script به این فریم مخفی فرستاده میشوند و چون مرورگرها محتوای html رو به صورت افزایشی (incrementally) رندر میکنن بنابراین این اسکریپتها بهترتیب زمان دریافت اجرا میشوند. (البته ظاهرا عبارت forever frame در صنعت عکاسی! معروفتره بنابراین در جستجو در زمینه این روش ممکنه کمی مشکل داشته باشین) (^).
- روش آخر که در کتابخونه SignalR ازش استفاده میشه long-polling نام داره. در روش polling معمولی پس از ارسال درخواست توسط کلاینت، سرور بلافاصله نتیجه حاصله رو به سمت کلاینت میفرسته و ارتباط قطع میشه. بنابراین برای دادههای جدید درخواست جدیدی باید به سمت سرور فرستاده بشه که تکرار این روش باعث افزایش شدید بار بر روی سرور و کاهش کارآمدی اون میشه. اما در روش long-polling پس از برقراری ارتباط کلاینت با سرور این ارتباط تا مدت زمان معینی (که توسط یه مقدار تایم اوت مشخص میشه و مقدار پیشفرضش 2 دقیقه است) برقرار میمونه. بنابراین کلاینت میتونه بدون ایجاد مشکلی در کارایی، دادههای جدید رو از سرور دریافت کنه. به این روش در برنامهنویسی وب اصطلاحا برنامهنویسی کامت (Comet Programming) میگن (^ ^).
(البته روشهای دیگری هم برای پیادهسازی برنامههای زمان اجرا وجود داره مثل کتابخونه node.js که جستجوی بیشتر به خوانندگان واگذار میشه)
SignalR برای برقراری ارتباط ابتدا بررسی میکنه که آیا هر دو سمت سرور و کلاینت قابلیت پشتیبانی از WebSocket رو دارند. در غیراینصورت سراغ روش Server-sent Events میره. اگر باز هم موفق نشد سعی به برقراری ارتباط با روش forever frame میکنه و اگر باز هم موفق نشد در آخر سراغ long-polling میره.
با استفاده از SignalR شما میتونین از سرور، متدهایی رو در سمت کلاینت فراخونی کنین. یعنی درواقع با استفاده از کدهای سی شارپ میشه متدهای جاوااسکریپت سمت کلاینت رو صدا زد!
بطور خلاصه در این کتابخونه دو کلاس پایه وجود داره:
- کلاس سطح پایین PersistentConnection
- کلاس سطح بالای Hub
علت این نامگذاری به این دلیله که کلاس سطح پایین پیادهسازی پیچیدهتر و تنظیمات بیشتری نیاز داره اما امکانات بیشتری هم در اختیار برنامهنویس قرار میده.
خوب پس از این مقدمه نسبتا طولانی برای دیدن یک مثال ساده میتونین با استفاده از نوگت (Nuget) مثال زیر رو نصب و اجرا کنین (اگه تا حالا از نوگت استفاده نکردین قویا پیشنهاد میکنم که کار رو با دریافتش از اینجا آغاز کنین) :
PM> Install-Package SignalR.Sample
پس از کامل شدن نصب این مثال اون رو اجرا کنین. این یک مثال فرضی ساده از برنامه نمایش ارزش آنلاین سهام برخی شرکتهاست. میتونین این برنامه رو همزمان در چند مرورگر اجرا کنین و نتیجه رو مشاهده کنین.
حالا میریم سراغ یک مثال ساده. میخوایم یک برنامه چت ساده بنویسیم. ابتدا یک برنامه وب اپلیکیشن خالی رو ایجاد کرده و با استفاده از دستور زیر در خط فرمان نوگت، کتابخونه SignalR رو نصب کنین:
PM> Install-Package SignalR
پس از کامل شدن نصب این کتابخونه، ریفرنسهای زیر به برنامه اضافه میشن:
Microsoft.Web.Infrastructure Newtonsoft.Json SignalR SignalR.Hosting.AspNet SignalR.Hosting.Common
برای کسب اطلاعات مختصر و مفید از تمام اجزای این کتابخونه به اینجا مراجعه کنین.
همچنین اسکریپتهای زیر به پوشه Scripts اضافه میشن (این نسخهها مربوط به زمان نگارش این مطلب است):
jquery-1.6.4.js jquery.signalR-0.5.1.js
بعد یک کلاس با نام SimpleChat به برنامه اضافه و محتوای زیر رو در اون وارد کنین:
using SignalR.Hubs; namespace SimpleChatWithSignalR { public class SimpleChat : Hub { public void SendMessage(string message) { Clients.reciveMessage(message); } } }
دقت کنین که این کلاس از کلاس Hub مشتق شده و همچنین خاصیت Clients از نوع dynamic است. (در مورد جزئیات این کتابخونه در قسمتهای بعدی توضیحات مفصلتری داده میشه)
سپس یک فرم به برنامه اضافه کرده و محتوای زیر رو در اون اضافه کنین:
<input type="text" id="msg" /> <input type="button" value="Send" id="send" /><br /> <textarea id='messages' readonly="true" style="height: 200px; width: 200px;"></textarea> <script src="Scripts/jquery-1.6.4.min.js" type="text/javascript"></script> <script src="Scripts/jquery.signalR-0.5.1.min.js" type="text/javascript"></script> <script src="signalr/hubs" type="text/javascript"></script> <script type="text/javascript"> var chat = $.connection.simpleChat; chat.reciveMessage = function (msg) { $('#messages').val($('#messages').val() + "-" + msg + "\r\n"); }; $.connection.hub.start(); $('#send').click(function () { chat.sendMessage($('#msg').val()); }); </script>
همونطور که میبینین برنامه چت ما آماده شد! حالا برنامه رو اجرا کنین و با استفاده از دو مرورگر مختلف نتیجه رو مشاهده کنین.
نکته کلیدی کار SignalR در خط زیر نهفته است:
<script src="signalr/hubs" type="text/javascript"></script>
اگر محتوای آدرس فوق رو دریافت کنین میبینین که موتور این کتابخانه تمامی متدهای موردنیاز در سمت کلاینت رو با استفاده از کدهای جاوااسکریپت تولید کرده. البته در این کد تولیدی از نامگذاری camel Casing استفاده میشه، بنابراین متد SendMessage در سمت سرور بهصورت sendMessage در سمت کلاینت در دسترسه.
امیدوارم تا اینجا تونسته باشم علاقه شما به استفاده از این کتابخونه رو جلب کرده باشم. در قسمتهای بعد موارد پیشرفتهتر این کتابخونه معرفی میشه.
اگه علاقهمند باشین میتونین از این ویکی اطلاعات بیشتری بدست بیارین.
به روز رسانی
در دورهای به نام SignalR در سایت، به روز شدهای این مباحث را میتوانید مطالعه کنید.
به روز رسانی
در دورهای به نام SignalR در سایت، به روز شدهای این مباحث را میتوانید مطالعه کنید.
شروع به کار با NH به دو قسمت تقسیم میشود. یک قسمت نگاشت کلاسها است و قسمت دوم سشن گردانی آن. قسمت دوم آن به همان مباحث کلاسهای singleton ایی که بحث آنها در سایت هست بر میگردد. یا حتی استفاده از کتابخانههای IOC برای مدیریت آن (که این پیاده سازی را به صورت توکار هم دارند).
قسمت نگاشت کلاسها در NH انواع و اقسامی دارد:
- ابتدا همان فایلهای XML مدل Hibernate جاوا بود.
- بعد شد مدل annotation ایی به نام Castle ActiveRecord. (این پروژه آنچنان فعال نیست و علتش به این بر میگردد که نویسنده اصلی جذب مایکروسافت شده)
- سپس Fluent NHibernate پدید آمد. (این پروژه هم پس از NH 3.2 ، سرد شده و به نظر آنچنان فعال نیست)
- الان هم مدل جدیدی به صورت توکار و بدون نیاز به کتابخانههای جانبی از NH 3.2 به بعد به آن اضافه شده به نام mapping-by-code .
و ... خبر خوب اینکه شخصی در 18 قسمت به توضیح این قابلیت جدید mapping by code پرداخته و روشهای نگاشت مرتبط رو با مثال توضیح داده که در آدرس زیر میتونید اونها رو پیدا کنید:
اعتماد و یا فقدان آن، عامل شماره یک مسدود کردن استفاده از نرم افزار به عنوان خدمات است. معماری پایگاه داده چند مستاجری برای رسیدگی به مشکل نرم افزار به عنوان سرویس (SaaS) که میتواند خدمات به تعدادی کلاینت ارائه کند استفاده میشود . معماری دیتابیس چند مستاجری وقتی مفید است که یک نمونه از دیتابیس به تعدادی کلاینت خدمات دهد. وقتی که نرم افزارهای محلی نصب میکنید نرم افزارهای به عنوان یک سرویس با مشتریان متمرکز، دسترسی به دادهها مبتنی بر شبکه با سربار کمتر را فراهم میکنند. اما به منظور برخورداری بیشتر از مزیتهای یک نرم افزار سرویس، یک سازمان باید از سطحی از کنترل روی داده صرفنظر کند و به فروشنده نرم افزار جهت نگهداری و امنیت به دور از چشم آنها اعتماد کند.
برای به درست آوردن این اعتماد، یکی از بالاترین الویت ها، آینده نگری معماری نرم افزار و ساخت یک معماری داده است که باید هر دو قوی و به اندازه کافی ایمن باشد، این دو برای راضی کردن مستاجران و کلاینت هایی که علاقمند هستند کنترل دادههای حیاتی تجارت خود را به شخص سومی واگذار نمایند، موثر است در حالی که برای اداره کردن و نگهداری مقرون به صرفه است.
سه روش مدیریت چند مستاجری داده
انتخاب روش مناسب برای برنامه شما به عوامل زیر بستگی دارد :
1) دیتابیسهای جداگانه برای هر مستاجر :
ذخیره سازی دادههای مستاجران در دیتابیسهای جداگانه سادهترین روش است. در این روش هر مستاجر یک دیتابیس دارد. منابع و کدهای برنامه معمولا در سرور بین همه مستاجران مشترک است اما هر مستاجر مجموعه ای از داده دارد که بطور منطقی از سایر مستاجران جدا شده است.
مزایا :
معایب:
2) دیتابیس مشترک و schema جداگانه برای هر مستاجر :
خدمات دهی به چندین مستاجر در یک دیتابیس مشترک اما هر مستاجر یک مجموعه از جداول گروهبندی شده دارد که با Schema جدا شده است که برای هر مستاجر الزامی است.
مزایا :
معایب:
3) دیتابیس مشترک و schema مشترک :
این روش شمامل یک دیتابیس و یک مجموعه از جداول برای چندین مستاجر است. دادههای جدول میتواند شامل رکوردهای هر مستاجر باشد
مزایا :
منابع :
http://msdn.microsoft.com/en-us/library/aa479086.aspx
http://www.codeproject.com/Articles/51334/Multi-Tenants-Database-Architecture
برای به درست آوردن این اعتماد، یکی از بالاترین الویت ها، آینده نگری معماری نرم افزار و ساخت یک معماری داده است که باید هر دو قوی و به اندازه کافی ایمن باشد، این دو برای راضی کردن مستاجران و کلاینت هایی که علاقمند هستند کنترل دادههای حیاتی تجارت خود را به شخص سومی واگذار نمایند، موثر است در حالی که برای اداره کردن و نگهداری مقرون به صرفه است.
سه روش مدیریت چند مستاجری داده
- دیتابیسهای جداگانه برای هر مستاجر
- دیتابیس مشترک و schema جداگانه برای هر مستاجر
- دیتابیس مشترک و schema مشترک
انتخاب روش مناسب برای برنامه شما به عوامل زیر بستگی دارد :
- سایز دیتابیس هر مستاجر
- تعداد مستاجران
- تعداد کاربران هر مستاجر
- نرخ رشد مستاجر
- نرخ رشد دیتابیس مستاجر
- امنیت
- هزینه
1) دیتابیسهای جداگانه برای هر مستاجر :
ذخیره سازی دادههای مستاجران در دیتابیسهای جداگانه سادهترین روش است. در این روش هر مستاجر یک دیتابیس دارد. منابع و کدهای برنامه معمولا در سرور بین همه مستاجران مشترک است اما هر مستاجر مجموعه ای از داده دارد که بطور منطقی از سایر مستاجران جدا شده است.
مزایا :
- امنیت بیشتر
- سهولت سفارشی سازی برای هر مستاجر
- سهولت نگهداری ( Backup و Restore ) برای هر مستاجر
معایب:
- برای نگهداری سخت افزار قوی مورد نیاز است
- این روش هزینه بیشتری برای تجهیزات ( Backup و Restore ) برای هر مستاجر دارد
2) دیتابیس مشترک و schema جداگانه برای هر مستاجر :
خدمات دهی به چندین مستاجر در یک دیتابیس مشترک اما هر مستاجر یک مجموعه از جداول گروهبندی شده دارد که با Schema جدا شده است که برای هر مستاجر الزامی است.
مزایا :
- برای دیتابیس برنامههای کوچک مناسب است. وقتی تعداد جداول برای هر مشتری کم است
- هزینه کمتری نسبت به روش اول دارد
- برای مشتریانی که نگران امنیت هستند، سطح منطقی مناسبی برای جداسازی داده ه وجود دارد
معایب:
- اطلاعات مستاجران در صورت بروز خطا به سختی restore میشود
- مدیریت آن برای دیتابیسهای بزرگ مشکل است
3) دیتابیس مشترک و schema مشترک :
این روش شمامل یک دیتابیس و یک مجموعه از جداول برای چندین مستاجر است. دادههای جدول میتواند شامل رکوردهای هر مستاجر باشد
مزایا :
- در مقایسه با روش قبلی، کمترین هزینه سخت افزاری را دارد
- میتواند مستاجران بیشتری رادر هر سرور پشتیبانی کند
- قابلیت بروز رسانی آسان در یک جا برای همه مستاجران
- مدیریت آسان دیتابیس و خطا و Backup و Restore
- امنیت بیشتری مورد نیاز است تا مطمئن شوید هیچکس به اطلاعات سایر مستاجران دسترسی ندارد.
- میتواند روی کارایی کوئریها تاثیر بگذارد چون تعداد رکوردها زیاد است.
- بروزرسانی و سفارشی کردن فقط برای یک مستاجر سخت است
منابع :
http://msdn.microsoft.com/en-us/library/aa479086.aspx
http://www.codeproject.com/Articles/51334/Multi-Tenants-Database-Architecture