‫۱۱ سال و ۶ ماه قبل، چهارشنبه ۱۴ فروردین ۱۳۹۲، ساعت ۱۵:۴۸
لایه سرویس شما می‌تونه متد Paging دار هم داشته باشه. مثلا:
        public IList<BlogPost> GetLatestBlogPosts(int pageNumber, int recordsPerPage = 4)
        {
            var skipRecords = pageNumber * recordsPerPage;
            return _blogPosts
                        .OrderByDescending(x => x.Id)
                        .Skip(skipRecords)
                        .Take(recordsPerPage)
                        .ToList();
        }
در این حالت در بدنه این متد لایه سرویس از IQueryable استفاده شده اما خروجی آن یک لیست مشخص است.
‫۱۱ سال و ۶ ماه قبل، چهارشنبه ۱۴ فروردین ۱۳۹۲، ساعت ۱۵:۴۳
- برای فایل‌های جاوا اسکریپت توصیه من این است:
الف) اگر از Web forms استفاده می‌کنید: استفاده از Script manager (^ و ^)
ب) اگر از MVC استفاده می‌کنید: استفاده از Bundling & minification
در هر دو حالت نحوه ارائه اسکریپت‌ها تحت کنترل برنامه ASP.NET در خواهد آمد و مستقیما و بدون دخالت ASP.NET، توسط IIS توزیع نمی‌شوند.
- برای مپ کردن فایل‌های استاتیک به موتور ASP.NET می‌شود از StaticFileHandler استفاده کرد. اگر کش کردن اطلاعات استاتیک در سمت سرور فعال شود، این مساله بار اضافه‌ای را به سرور تحمیل نخواهد کرد.
<system.web>
   <httpHandlers>
      <add path="*.js" verb="*" type="System.Web.StaticFileHandler" />
   </httpHandlers>
‫۱۱ سال و ۶ ماه قبل، چهارشنبه ۱۴ فروردین ۱۳۹۲، ساعت ۱۵:۲۷
نشتی طراحی مد نظر بوده؛ نه نشتی حافظه. نشتی طراحی به این معنا است که اگر متد شما خروجی IQueryable داشته باشه، در لایه‌های دیگر می‌شود کلا مقصود آن‌را تغییر شکل داد به فرم دیگری که اصلا شاید هدف اولیه این نبوده (چون IQueryable یک عبارت است و نه اجرای یک فرمان). به همین جهت باید در لایه سرویس و بدنه متدهای آن از IQueryable استفاده شود و نهایتا این متدها باید IList یا IEnumerable را بازگشت دهند. به این ترتیب حد و مرز یک لایه مشخص می‌شود.
‫۱۱ سال و ۶ ماه قبل، سه‌شنبه ۱۳ فروردین ۱۳۹۲، ساعت ۱۴:۰۸
- ابتدای کار یک روش غلط رو شروع کرده، بعد اواسط کار اون رو نقد کرده و رد.
- چون از لایه سرویس استفاده نکرده کل منطق کار رو برده داخل کنترلرها.
- از تزریق وابستگی‌ها استفاده نکرده، بنابراین برخلاف شکلی که در ابتدای کار گذاشته، کنترلرهاش رو نمی‌تونه مستقل از یک سری کلاس کاملا مشخص، تست کنه.
- الگوی مخزنی که ارائه داده در این مثال ساده کار می‌کنه اما اگر قرار باشه با چند موجودیت کار کرد و نتیجه رو ترکیب، کارآیی خوبی نداره چون خیلی از قابلیت‌های ذاتی EF مثل کوئری‌های به تاخیر افتاده (deferred LINQ queries) در اینجا قابل پیاده سازی نیست. اگر هم بخوان این رو اضافه کنن باید به لایه مخزن خروجی IQueryable اضافه کنن که به یک طراحی نشتی دار خواهند رسید چون انتهای کار با خروجی IQueryable کاملا باز باقی می‌ماند (نمونه‌اش متد Get ایی است که طراحی کرده).
یا یکی دیگر از اهداف ظاهری لایه مخزن، امکان تعویض آن در صورت نیاز است و مثلا کوچ به یک ORM دیگر. دنیای واقعی: include ایی که اینجا تعریف شده فقط در EF وجود خارجی دارد یا یک سری از نکات دیگر بکار گرفته شده در این الگوی مخزن. (در قسمت 11 سری EF سایت بحث شده)
- در مثالی که زده باگ امنیتی وجود دارد. متد Updateاش به دلیل عدم استفاده از ViewModel آسیب پذیر هست. (در این مورد در سری MVC بحث شده)
‫۱۱ سال و ۶ ماه قبل، یکشنبه ۱۱ فروردین ۱۳۹۲، ساعت ۱۶:۵۷
AppDomain  روشی است برای ایزوله سازی اطلاعات برنامه‌ها از یکدیگر. به این ترتیب در یک پروسه هم می‌شود چندین برنامه دیگر را به صورت کاملا ایزوله از هم بارگذاری و اجرا کرد.
‫۱۱ سال و ۶ ماه قبل، یکشنبه ۱۱ فروردین ۱۳۹۲، ساعت ۱۵:۰۸
این یک روش عمومی است و در تمام رشته‌های اتصالی دات نتی کار می‌کند:
از DataDirectory استفاده کنید. مثلا:

AttachDBFilename=|DataDirectory|\database.mdf
مقدار آن در برنامه‌های ASP.NET به صورت خودکار به پوشه استاندارد App_Data مپ می‌شود. برای سایر حالات می‌تونید اون رو در زمان آغاز برنامه دستی مقدار دهی کنید:
AppDomain.CurrentDomain.SetData("DataDirectory", "C:\myDB");
ضمنا روش مسیردهی کامل هم همیشه کار می‌کند
AttachDbFilename='Full\Path\To.MDF'
‫۱۱ سال و ۶ ماه قبل، شنبه ۱۰ فروردین ۱۳۹۲، ساعت ۰۴:۴۶
لطفا روی لینک مطرح شده در سطر اول مطلب فوق کلیک کنید. کل بحث جاری در مورد استخراج اطلاعات و تبدیل فرمت خاص صفحه وبی بود که ملاحظه می‌کنید. این صفحه هم عمومی است (هر چند ظاهر ساده‌ای دارد، اما پشت صحنه و سورس آن، متن زمانبندی شده کل دوره است).
‫۱۱ سال و ۶ ماه قبل، چهارشنبه ۷ فروردین ۱۳۹۲، ساعت ۲۱:۱۶
یک نکته تکمیلی یا یک ... تجربه:
منهای موتورهای جستجوی خوب در اینترنت، مابقی قدرت پردازش لینک‌های یونیکد را ندارند. به همین جهت از متد EmitCleanUnicodeUrl استفاده نکنید. مهم نیست که این لینک‌ها در IE شکل زیبایی نخواهند داشت، مهم این است که تعداد خطاهای لاگ شده در برنامه شما در اثر عدم قدرت پردازش لینک‌های یونیکد توسط بسیاری از ربات‌های متفرقه به حداقل می‌رسد.
‫۱۱ سال و ۶ ماه قبل، چهارشنبه ۷ فروردین ۱۳۹۲، ساعت ۱۷:۳۹
لطفا مراجعه کنید به ابتدای گروه EF در سایت. لینک دریافت PDF کلیه مطالب گروه به صورت یکجا قرار دارد. این نکته در مورد سایر گروه‌های سایت هم صادق است.