‫۱۲ سال و ۱ ماه قبل، چهارشنبه ۲۹ شهریور ۱۳۹۱، ساعت ۲۳:۴۲
این قسمت پایه تئوری قسمت‌های بعدی است.
در قسمت‌های بعد با مباحث امنیتی و فیلترهای مربوطه آشنا خواهید شد که استفاده از آن‌ها در هر برنامه‌ای ضروری است.
‫۱۲ سال و ۱ ماه قبل، چهارشنبه ۲۹ شهریور ۱۳۹۱، ساعت ۱۹:۳۶
نه به این شکل. نیازی به وهله سازی PublishingContext نیست چون الگوی واحد کار را نقض می‌کند؛ چون هر وهله سازی Context یعنی یک تراکنش جدا. از uow استفاده کنید. کار تزریق وابستگی‌ها توسط StructureMap در حالت service locator هم در لایه‌های زیرین انجام می‌شود. بنابراین کار مانند قبل است. فقط در کلاس CustomRoleProvider برخلاف معمول باید از ObjectFactory.GetInstance استفاده کرد. مابقی مسایل تفاوتی نمی‌کند.
‫۱۲ سال و ۱ ماه قبل، چهارشنبه ۲۹ شهریور ۱۳۹۱، ساعت ۱۶:۵۶
باید دسترسی به سرور شما داشت تا بشود اظهار نظر کرد. دسترسی‌ها چی هست. یوزرها به چه بانک‌های اطلاعاتی دسترسی دارند و مسایلی از این دست که از راه دور قابل بررسی نیست.
ولی درکل در اینجا از دیتابیس سیستمی master برای ساخت جدول Logging استفاده شده. این رو تغییر بدید به یک دیتابیس دیگر با سطح دسترسی عمومی.

USE [dbName]
go
INSERT INTO [dbName].schemaName.[Logging]
...
‫۱۲ سال و ۱ ماه قبل، چهارشنبه ۲۹ شهریور ۱۳۹۱، ساعت ۱۴:۰۱
این‌ها بیشتر مباحث طراحی API است. اگر از List استفاده کنید، مصرف کننده کتابخانه شما مجبور است فقط از List استفاده کند. List صرفا یک پیاده سازی خاص از IList است.
اگر از اینترفیس و قرارداد IList استفاده شود، آزادی عمل بیشتری را در اختیار مصرف کننده خواهید گذاشت. در اینجا مصرف کننده می‌تواند از هر پیاده سازی دلخواهی از IList برای کار با API شما استفاده کند. حتی مواردی که در زمان طراحی API اصلی وجود خارجی نداشته‌اند و بعدها پیاده سازی خواهند شد.

‫۱۲ سال و ۱ ماه قبل، سه‌شنبه ۲۸ شهریور ۱۳۹۱، ساعت ۲۲:۰۲
مشکل اصلی به اینجا بر می‌گرده که کامپایلر سی++ جدید مایکروسافت، فایل اجرایی سازگار با ویندوز XP تولید نمی‌کند. قسمت‌هایی از دات نت هم با کامپایلر سی++ تهیه شدن. قرار شده اواخر پائیز، این محدودیت برداشته بشه. شاید در آن زمان این مسایل را تغییر دادند، شاید هم خیر.
 
‫۱۲ سال و ۱ ماه قبل، سه‌شنبه ۲۸ شهریور ۱۳۹۱، ساعت ۲۰:۵۸
بستگی به مکان استفاده داره. اگر قرار است دو یا چند جستجو را انجام دهید، اینکارها باید با IQueryable داخل یک متد انجام شود، اما خروجی متد فقط باید لیست حاصل باشد؛ نه IQueryable ایی که انتهای آن باز است و سبب نشتی لایه سرویس شما در لایه‌های دیگر خواهد شد. IQueryable فقط یک expression است. هنوز اجرا نشده. زمانیکه ToList، First و امثال آن روی این عبارت فراخوانی شود تبدیل به SQL شده و سپس بر روی بانک اطلاعاتی اجرا می‌شود. به این deferred execution یا اجرای به تعویق افتاده گفته می‌شود.
اگر این عبارت را در اختیار لایه‌های دیگر قرار دهید، یعنی انتهای کار را بازگذاشته‌اید و حد و حدود سیستم شما مشخص نیست. شما اگر IQueryable بازگشت دهید، در لایه‌ای دیگر می‌شود یک join روی آن نوشت و اطلاعات چندین جدول دیگر را استخراج کرد؛ درحالیکه نام متد شما GetUsers بوده. بنابراین بهتر است به صورت صریح اطلاعات را به شکل List بازگشت دهید، تا انتهای کار باز نمانده و طراحی شما نشتی نداشته باشد.
طراحی یک لایه سرویس که خروجی IQueryable دارد نشتی دار درنظر گرفته شده و توصیه نمی‌شود. اصطلاحا leaky abstraction هم به آن گفته می‌شود؛ چون طراح نتوانسته حد و مرز سیستم خودش را مشخص کند و همچنین نتوانسته سازوکار درونی آن‌را به خوبی کپسوله سازی و مخفی نماید. 
‫۱۲ سال و ۱ ماه قبل، سه‌شنبه ۲۸ شهریور ۱۳۹۱، ساعت ۲۰:۴۸
- خیر. نام کامل این محصول «SQL Server Express LocalDB » است + نسخه «Microsoft® SQL Server® 2012 Express» از اینجا قابل دریافت است. بنابراین جایگزین یا حذف نشده.
- هدف اصلی از LocalDb ارائه یک «embedded database» جدید از طرف مایکروسافت است.
بنابراین هدف آن استفاده تحت شبکه نیست. جاهایی استفاده می‌شود که تک کاربر نهایی دانش آنچنانی در نصب و نگهداری بانک‌های اطلاعاتی ندارد و برنامه و سیستم بانک اطلاعاتی او یکپارچه به نظر می‌رسند. از این نمونه بانک‌های اطلاعاتی embedded باز هم هستند. مانند Firebird Embedded ، SQLite، SQL CE و غیره.
- نسخه Express تحت شبکه قابل استفاده است؛ البته نیاز به تنظیم دارد.

‫۱۲ سال و ۱ ماه قبل، سه‌شنبه ۲۸ شهریور ۱۳۹۱، ساعت ۱۴:۲۹
خروجی SQL شما منطبق با خروجی SQL حاصل از EF نیست. روش کار را اینجا توضیح دادم که چگونه می‌شود این خروجی را دقیقا به دست آورد.
در حالت
var list1 = ctx.Users.Where(x => x.Name != null).ToList();
این خروجی حاصل می‌شود:
SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent1].[Age] AS [Age]
FROM [dbo].[People] AS [Extent1]
WHERE [Extent1].[Name] IS NOT NULL
در حالت
var list2 = ctx.Users.Where(x => x.Name == null).ToList();
دقیقا این خروجی را خواهیم داشت:
SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent1].[Age] AS [Age]
FROM [dbo].[People] AS [Extent1]
WHERE [Extent1].[Name] IS NULL