وحید نصیری وحید نصیری
فایل‌های پروژه‌ها
PdfRpt-1.3.zip
- Removed the limitation of defining non duplicate column names. See DuplicateColumns sample for more info.
- Added horizontal stack panel mode. See CharacterMap sample for more info.
- Added pdfStamper to onFillAcroForm of PdfTemplate. See QuestionsAcroForm sample for more info.
Added 6 new samples:
- AccountingBalanceColumn
- CharacterMap
- CustomPriceNumber
- DuplicateColumns
- QuestionsAcroForm
- QuestionsForm
‫۱۱ سال و ۱۲ ماه قبل، جمعه ۵ آبان ۱۳۹۱، ساعت ۱۵:۵۱
وحید نصیری وحید نصیری
نظرات مطالب
بالا بردن سرعت بارگذاری اولیه EF Code first با تعداد مدل‌های زیاد
یک نکته‌ی تکمیلی: امکان بالابردن سرعت بارگذاری برنامه‌های مبتنی بر EF 6.2 به صورت توکار

با به روز رسانی ارجاعات EF مورد استفاده:
To Update 
PM> Update-Package EntityFramework -Version 6.2.0

To install
PM> Install-Package EntityFramework -Version 6.2.0
 تنها کافی است قطعه کد ذیل را به اسمبلی حاوی Context خود اضافه کنید:
public class MyDbConfiguration : DbConfiguration
{
   public MyDbConfiguration() : base()
   {
       SetModelStore(new DefaultDbModelStore(Directory.GetCurrentDirectory()));
   }
}
تشخیص و استفاده‌ی از آن توسط EF 6.2 خودکار است. پس از آن یک کش محلی، از مدل سیستم تهیه می‌شود (Entity Framework Code First Model Cache) و در مسیری که قید شده (پارامتر DefaultDbModelStore)، ذخیره خواهد شد؛ مانند:
 /bin/Debug/MyAssembly.MyNamespace.MyDbContext.edmx
بازسازی این کش محلی بجای تولید پویای آن در هربار بارگذاری برنامه (که سرعت آغاز برنامه را کاهش می‌دهد)، بر اساس مقایسه‌ی تاریخ آخرین تغییر اسمبلی حاوی Context برنامه با تاریخ آخرین تغییر فایل کش محلی است. اگر این دو یکی نبودند، این کش بازتولید خواهد شد.

پس از این تغییر کوچک، اولین بار اجرای برنامه همانند حالت تولید پویای Entity Framework Code First Model Cache که پیشتر در حافظه انجام می‌شد، اندکی طول کشیده و نتیجه‌ی آن در فایل edmx یاد شده ذخیره می‌شود. از بار دوم اجرای برنامه، Model Cache از فایل edmx محلی خوانده شده و به این ترتیب سرعت آغاز برنامه به شدت افزایش خواهد یافت.
برای نمونه عنوان شده‌است که با استفاده از این روش، سرعت بارگذاری Context ایی با 600 مدل، از 14 ثانیه به 2 ثانیه کاهش یافته‌است.

یک نکته: برای برنامه‌های وب بهتر است از مسیر پوشه‌ی محافظت شده‌ی App_Data به عنوان پارامتر DefaultDbModelStore استفاده کنید:
var appDataDirectory = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "App_Data");
//OR
var appDataDirectory = AppDomain.CurrentDomain.GetData("DataDirectory").ToString();
‫۶ سال و ۱۱ ماه قبل، پنجشنبه ۱۱ آبان ۱۳۹۶، ساعت ۱۴:۲۵
مسعود پاکدل مسعود پاکدل
نظرات مطالب
Repository ها روی UnitOfWork ایده خوبی نیستند
ممنونم جناب نصیری. دلیل اشاره من به عدم تست پذیری قابل قبول در حالت استفاده مستقیم از Context به خاطر وجود دستوراتی نظیر Entry of T یا موارد مربوط به ChangeTracking است که با تست درون حافظه ای نتیجه مطلوب حاصل نمی‌شود، در نتیجه بهتر است از Effort برای تست لایه دسترسی استفاده شود که عملیات را در قالب یک دیتابیس SqlCE تست می‌کند و نسخه Effort.Ef6  آن نیز از Entity Framework 6 به خوبی پشتیبانی می‌کند.
‫۱۰ سال و ۶ ماه قبل، سه‌شنبه ۹ اردیبهشت ۱۳۹۳، ساعت ۰۲:۳۲
مهران علویان مهران علویان
نظرات مطالب
اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity
سلام،

اگر بخوایم مقاله فعلی رو با درنظر گرفتن موارد زیر به یک برنامه ASP.NET Core اعمال کنیم به چه نحوی هستش؟

ممنون
‫۸ سال و ۲ ماه قبل، جمعه ۲۲ مرداد ۱۳۹۵، ساعت ۱۴:۳۴
سعد سعد
اشتراک‌ها
از کند شدن Entity Framework دوری کنید
Generally speaking, I don't worry much about tweaking my LINQ queries when working with Entity Framework (this is also true when I'm working with SQL directly, by the way). I'm always telling my clients that if they want to speed up their data access they should look at their database design and, especially, how they're using indexes.
از کند شدن Entity Framework دوری کنید
‫۶ سال و ۷ ماه قبل، یکشنبه ۶ اسفند ۱۳۹۶، ساعت ۱۴:۵۴
مهدی ملائیان مهدی ملائیان
اشتراک‌ها
من عاشق Entity Framework هستم ‍!

I love Entity Framework. I also like (not love) nHibernate. That’s right, as a DBA and data professional, I’m telling you I love Object/Relational Mapping tools (ORM). I think this is a technology set that the DBA needs to more tightly embrace. Let me tell you why. 

من عاشق Entity Framework هستم ‍!
‫۷ سال و ۳ ماه قبل، شنبه ۱۷ تیر ۱۳۹۶، ساعت ۱۴:۵۴
وحید نصیری وحید نصیری
مطالب
روش‌هایی برای بهبود سرعت برنامه‌های مبتنی بر Entity framework
در این مطلب تعدادی از شایع‌ترین مشکلات حین کار با Entity framework که نهایتا به تولید برنامه‌هایی کند منجر می‌شوند، بررسی خواهند شد.

مدل مورد بررسی 

    public class User
    {
        public int Id { get; set; }
        public string Name { get; set; }

        public virtual ICollection<BlogPost> BlogPosts { get; set; }
    }

    public class BlogPost
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public string Content { get; set; }

        [ForeignKey("UserId")]
        public virtual User User { get; set; }
        public int UserId { get; set; }
    }
کوئری‌هایی که در ادامه بررسی خواهند شد، بر روی رابطه‌ی one-to-many فوق تعریف شده‌اند؛ یک کاربر به همراه تعدادی مطلب منتشر شده.


مشکل 1: بارگذاری تعداد زیادی ردیف 
 var data = context.BlogPosts.ToList();
در بسیاری از اوقات، در برنامه‌های خود تنها نیاز به مشاهده‌ی قسمت خاصی از یک سری از اطلاعات، وجود دارند. به همین جهت بکارگیری متد ToList بدون محدود سازی تعداد ردیف‌های بازگشت داده شده، سبب بالا رفتن مصرف حافظه‌ی سرور و همچنین بالا رفتن میزان داده‌ای که هر بار باید بین سرور و کلاینت منتقل شوند، خواهد شد. یک چنین برنامه‌هایی بسیار مستعد به استثناهایی از نوع out of memory هستند.
راه حل:  با استفاده از Skip و Take، مباحث صفحه‌ی بندی را اعمال کنید.


مشکل 2: بازگرداندن تعداد زیادی ستون 
 var data = context.BlogPosts.ToList();
فرض کنید View برنامه، در حال نمایش عناوین مطالب ارسالی است. کوئری فوق، علاوه بر عناوین، شامل تمام خواص تعریف شده‌ی دیگر نیز هست. یک چنین کوئری‌هایی نیز هربار سبب هدر رفتن منابع سرور می‌شوند.
راه حل: اگر تنها نیاز به خاصیت Content است، از Select و سپس ToList استفاده کنید؛ البته به همراه نکته 1.
 var list = context.BlogPosts.Select(x => x.Content).Skip(15).Take(15).ToList();


مشکل 3: گزارشگیری‌هایی که بی‌شباهت به حمله‌ی به دیتابیس نیستند 
 foreach (var post in context.BlogPosts)
{
     Console.WriteLine(post.User.Name);
}
فرض کنید قرار است رکوردهای مطالب را نمایش دهید. در حین نمایش این مطالب، در قسمتی از آن باید نام نویسنده نیز درج شود. با توجه به رابطه‌ی تعریف شده، نوشتن post.User.Name به ازای هر مطلب، بسیار ساده به نظر می‌رسد و بدون مشکل هم کار می‌کند. اما ... اگر خروجی SQL این گزارش را مشاهده کنیم، به ازای هر ردیف نمایش داده شده، یکبار رفت و برگشت به بانک اطلاعاتی، جهت دریافت نام نویسنده یک مطلب وجود دارد.
این مورد به lazy loading مشهور است و در مواردی که قرار است با یک مطلب و یک نویسنده کار شود، شاید اهمیتی نداشته باشد. اما در حین نمایش لیستی از اطلاعات، بی‌شباهت به یک حمله‌ی شدید به بانک اطلاعاتی نیست.
راه حل: در گزارشگیری‌ها اگر نیاز به نمایش اطلاعات روابط یک موجودیت وجود دارد، از متد Include استفاده کنید تا Lazy loading لغو شود.
 foreach (var post in context.BlogPosts.Include(x=>x.User))


مشکل 4:  فعال بودن بی‌جهت مباحث ردیابی اطلاعات 
 var data = context.BlogPosts.ToList();
در اینجا ما فقط قصد داریم که لیستی از اطلاعات را دریافت و سپس نمایش دهیم. در این بین، هدف، ویرایش یا حذف اطلاعات این لیست نیست. یک چنین کوئری‌هایی مساوی هستند با تشکیل dynamic proxies مخصوص EF جهت ردیابی تغییرات اطلاعات (مباحث AOP توکار). EF توسط این dynamic proxies، محصور کننده‌هایی را برای تک تک آیتم‌های بازگشت داده شده از لیست تهیه می‌کند. در این حالت اگر خاصیتی را تغییر دهید، ابتدا وارد این محصور کننده (غشاء نامرئی) می‌شود، در سیستم ردیابی EF ذخیره شده و سپس به شیء اصلی اعمال می‌گردد. به عبارتی شیء در حال استفاده، هر چند به ظاهر post.User است اما در واقعیت یک User دارای روکشی نامرئی از جنس dynamic proxy‌های EF است. تهیه این روکش‌ها، هزینه‌بر هستند؛ چه از لحاظ میزان مصرف حافظه و چه از نظر سرعت کار.
راه حل: در گزاشگیری‌ها، dynamic proxies را توسط متد AsNoTracking غیرفعال کنید:
 var data = context.BlogPosts.AsNoTracking().Skip(15).Take(15).ToList();


مشکل 5: باز کردن  تعداد اتصالات زیاد به بانک اطلاعاتی در طول یک درخواست

هر Context دارای اتصال منحصربفرد خود به بانک اطلاعاتی است. اگر در طول یک درخواست، بیش از یک Context مورد استفاده قرار گیرد، بدیهی است به همین تعداد اتصال باز شده به بانک اطلاعاتی، خواهیم داشت. نتیجه‌ی آن فشار بیشتر بر بانک اطلاعاتی و همچنین کاهش سرعت برنامه است؛ از این لحاظ که اتصالات TCP برقرار شده، هزینه‌ی بالایی را به همراه دارند.
روش تشخیص:
        private void problem5MoreThan1ConnectionPerRequest() 
        {
            using (var context = new MyContext())
            {
                var count = context.BlogPosts.ToList();
            }
        }
داشتن متدهایی که در آن‌ها کار وهله سازی و dispose زمینه‌ی EF انجام می‌شود (متدهایی که در آن‌ها new Context وجود دارد).
راه حل: برای حل این مساله باید از روش‌های تزریق وابستگی‌ها استفاده کرد. یک Context وهله سازی شده‌ی در طول عمر یک درخواست، باید بین وهله‌های مختلف اشیایی که نیاز به Context دارند، زنده نگه داشته شده و به اشتراک گذاشته شود.


مشکل 6: فرق است بین IList و IEnumerable 
DataContext = from user in context.Users
                      where user.Id>10
                      select user;
خروجی کوئری LINQ نوشته شده از نوع IEnumerable است. در EF، هربار مراجعه‌ی مجدد به یک کوئری که خروجی IEnumerable دارد، مساوی است با ارزیابی مجدد آن کوئری. به عبارتی، یکبار دیگر این کوئری بر روی بانک اطلاعاتی اجرا خواهد شد و رفت و برگشت مجددی صورت می‌گیرد.
زمانیکه در حال تهیه‌ی گزارشی هستید، ابزارهای گزارشگیر ممکن است چندین بار از نتیجه‌ی کوئری شما در حین تهیه‌ی گزارش استفاده کنند. بنابراین برخلاف تصور، data binding انجام شده، تنها یکبار سبب اجرای این کوئری نمی‌شود؛ بسته به ساز و کار درونی گزارشگیر، چندین بار ممکن است این کوئری فراخوانی شود.
راه حل: یک ToList را به انتهای این کوئری اضافه کنید. به این ترتیب از نتیجه‌ی کوئری، بجای اصل کوئری استفاده خواهد شد و در این حالت تنها یکبار رفت و برگشت به بانک اطلاعاتی را شاهد خواهید بود.


مشکل 7: فرق است بین IQueryable و IEnumerable

خروجی IEnumerable، یعنی این عبارت را محاسبه کن. خروجی IQueryable یعنی این عبارت را درنظر داشته باش. اگر نیاز است نتایج کوئری‌ها با هم ترکیب شوند، مثلا بر اساس رابط کاربری برنامه، کاربر بتواند شرط‌های مختلف را با هم ترکیب کند، باید از ترکیب IQueryableها استفاده کرد تا سبب رفت و برگشت اضافی به بانک اطلاعاتی نشویم.


مشکل 8: استفاده از کوئری‌های Like دار 
 var list = context.BlogPosts.Where(x => x.Content.Contains("test"))
این نوع کوئری‌ها که در نهایت به Like در SQL ترجمه می‌شوند، سبب full table scan خواهند شد که کارآیی بسیار پایینی دارند. در این نوع موارد توصیه شده‌است که از روش‌های full text search استفاده کنید.


مشکل 9: استفاده از Count بجای Any

اگر نیاز است بررسی کنید مجموعه‌ای دارای مقداری است یا خیر، از Count>0 استفاده نکنید. کارآیی Any و کوئری SQL ایی که تولید می‌کند، به مراتب بیشتر و بهینه‌تر است از Count>0.


مشکل 10: سرعت insert پایین است

ردیابی تغییرات را خاموش کرده و از متد جدید AddRange استفاده کنید. همچنین افزونه‌هایی برای Bulk insert نیز موجود هستند.


مشکل 11: شروع برنامه کند است

می‌توان تمام مباحث نگاشت‌های پویای کلاس‌های برنامه به جداول و روابط بانک اطلاعاتی را به صورت کامپایل شده در برنامه ذخیره کرد. این مورد سبب بالا رفتن سرعت شروع برنامه خصوصا در حالتیکه تعداد جداول بالا است می‌شود.
‫۱۰ سال و ۴ ماه قبل، چهارشنبه ۴ تیر ۱۳۹۳، ساعت ۱۵:۴۰
محسن افشین محسن افشین
اشتراک‌ها
15 درس هنگام مهاجرت به .NET Core
1. Using xproj & csproj files together
2. Building for deployment
3. NetStandard vs NetCoreApp1.0
4. IIS is dead, well sort of
5. HttpModules and HttpHandlers are replaced by new “middleware”
6. FileStream moved to System.IO.FileSystem ???
7. StreamReader constructor no longer works with a file path
8. Platform specific code… like Microsoft specific RSA
9. Newtonsoft changed to default to camel case on field names 🙁
10. Log4net doesn’t work and neither do countless other dependencies, unless you target .NET 4.5!
11. System.Drawing doesn’t exist
12. DataSet and DataTable doesn’t exist
13. Visual Studio Tooling
14. HttpWebRequest weird changes
15. Creating a Windows Service in .NET Core 
15 درس هنگام مهاجرت به .NET Core
‫۸ سال و ۲ ماه قبل، پنجشنبه ۲۸ مرداد ۱۳۹۵، ساعت ۱۴:۲۱
وحید محمدطاهری وحید محمدطاهری
اشتراک‌ها
کتابخانه Gijgo
jQuery Grid by Gijgo.com is a plug-in for the jQuery Javascript library. It is a very fast and extandable tool, and will add advanced interaction controls to any HTML table. This plugin support pagination, javascript and server side data sources, jQuery UI and Bootstrap.  Demo
کتابخانه Gijgo
‫۹ سال و ۴ ماه قبل، یکشنبه ۳۱ خرداد ۱۳۹۴، ساعت ۱۹:۲۵