‫۱۲ سال و ۱ ماه قبل، سه‌شنبه ۲۸ شهریور ۱۳۹۱، ساعت ۱۴:۱۵
- در متن فوق قسمت ششم توضیح داده شده: «اگر علاقمند نیستید که primary key شما از نوع identity باشد، می‌توانید از گزینه DatabaseGeneratedOption.None استفاده نمائید»
- ضمنا این روش کار نیست برای انتقال اطلاعات. اگر از sql server 2008 استفاده می‌کنید، امکان تهیه خروجی به صورت اسکریپت را دارد. یکی از نکاتی که در این اسکریپت لحاظ می‌شود، دو دستور IDENTITY_INSERT  زیر است که با SQL CE هم کار می‌کند:
SET IDENTITY_INSERT [table1] ON;
GO
INSERT INTO [table1] ([Id],...) VALUES (1,...);
GO
SET IDENTITY_INSERT [table1] OFF;
GO
برای اجرای اسکریپت نهایی می‌تونید از sql ce toolbox استفاده کنید.

‫۱۲ سال و ۱ ماه قبل، دوشنبه ۲۷ شهریور ۱۳۹۱، ساعت ۱۳:۴۳
می‌شود از VaryByParam استفاده کرد (مثال دوم فوق)
[OutputCache(Duration = 60, VaryByParam = "userId")]
public ActionResult Index(string userId)
البته کش کردن صفحاتی که نیاز به اعتبارسنجی دارند اشتباه است (نکته مهم انتهای بحث).
- از کلاس CacheManager مطرح شده در انتهای بحث استفاده کنید. کلید آن‌را مساوی یک عبارت منحصر به فرد مانند شماره کاربری به علاوه نام صفحه قرار دهید. مقدار آن را حاصل عملیات سنگینی که مد نظر دارید.
‫۱۲ سال و ۱ ماه قبل، دوشنبه ۲۷ شهریور ۱۳۹۱، ساعت ۰۴:۴۰
- EF 5 نسخه نهایی دارد. نیازی به نسخه بتا نیست.
- بهترین روش استفاده از NuGet است چون دفعه‌ی بعد که به روز رسانی شد به شما اطلاع خواهد داد. مانند به روز رسانی افزونه‌های فایرفاکس. به علاوه سورس آن هم در CodePlex موجود است.
- زمانیکه یکبار دریافت شد در پوشه packages شما قرار می‌گیرد. به این صورت در پروژه‌های دیگر هم قابل ارجاع است.
- توزیع فایل dll آن به همراه برنامه. نیازی به نصب ندارد.
‫۱۲ سال و ۱ ماه قبل، دوشنبه ۲۷ شهریور ۱۳۹۱، ساعت ۰۳:۴۷
شما در حال استفاده از EF 4.1 با دات نت 4 و نیم هستید. این دو با هم سازگاری ندارند. از EF 5 با دات نت 4 و نیم استفاده کنید تا مشکل تداخل فضاهای نامی که ذکر شده، برطرف شود.
‫۱۲ سال و ۱ ماه قبل، دوشنبه ۲۷ شهریور ۱۳۹۱، ساعت ۰۳:۳۹
- اگر کوئری SQL شما از ایندکس استفاده می‌کند نیازی به روش‌های full text search ندارید و موتورهای بانک اطلاعاتی به اندازه کافی برای مدیریت این نوع موارد سریع و بهینه هستند.
- جستجوی این سایت و یا full text search تک کلمه‌ای نیست. می‌تونید جمله هم بنویسید. کلا برای بهبود سرعت، کاهش مصرف CPU و حافظه کوئری‌های SQL ایی که از like استفاده می‌کنند، روش full text search پیشنهاد می‌شود.
استفاده از like در عبارات SQL روش بهینه‌ای نیست چون هربار full table scan صورت می‌گیرد (تصور کنید 100 نفر در حال جستجوی مطالبی در سایت هستند. در این حالت مصرف CPU، استهلاک هارد و مصرف بالای حافظه را درحین اسکن کامل جداول بانک اطلاعاتی درنظر بگیرید)

‫۱۲ سال و ۱ ماه قبل، دوشنبه ۲۷ شهریور ۱۳۹۱، ساعت ۰۲:۳۲
- بله. نیاز است مدام این ایندکس را به روز نگه داشت.
- برای این موارد متداول از تاریخ تا تاریخ، از همان SQL معمولی استفاده کنید. هر جایی که امکان تعریف ایندکس و کوئری‌های SQL ایی که از ایندکس استفاده می‌کنند، وجود دارد، روش‌های متداول SQLایی بهینه‌ترین روش‌ها هستند. هدف در اینجا، full text search است بر روی انبوهی text. جستجوی بسیار سریع روی فیلدهای ایندکس نشده حجیم متنی با کیفیتی بالا. این هدف full text search است. چیزی مثل جستجوی گوگل.
در غیر اینصورت نیاز خواهید داشت از عبارات sql به همراه like استفاده کنید که ... بسیار کند هستند؛ چون باید کل جداول و بانک اطلاعاتی را هربار اسکن کنند و در حالت استفاده از like از ایندکس استفاده نمی‌شود.
‫۱۲ سال و ۱ ماه قبل، یکشنبه ۲۶ شهریور ۱۳۹۱، ساعت ۱۶:۳۳
- IDbSet یک اینترفیس است؛ پیاده سازی نیست. اینترفیسی به همین نام را برای هر ORM دلخواه دیگری طراحی و پیاده سازی کنید. کدهای شما قابل انتقال خواهند بود.
- بله. دسترسی به خاصیت Local داخل لایه سرویس صورت گرفته و کپسوله شده. به همین جهت امضای متدی که ارائه شده به هر ORM دیگری نیز قابل انتقال است. فقط در آنجا یک تبدیل لیست به ObservableCollection را در پیاده سازی داخلی لایه سرویس خود خواهید داشت. اما استفاده کننده نهایی فقط با اینترفیس و قراردادهای تعریف شده در آن هست که کار می‌کند و کاری به جزئیات پیاده سازی لایه سرویس شما ندارد.
 به همین جهت است که در اینجا کار با اینترفیس‌ها و قراردادها ترویج شده؛ تا جزئیات پیاده سازی لایه سرویس از دید استفاده کننده مخفی باقی بماند.