- Added ShouldSkipRow, ShouldSkipFooter & ShouldSkipHeader events. See Events/EventsPdfReport.cs sample for more info. - Updated the project to use iTextSharp.5.5.5. - Improved: Font styles (size, color etc.) are not applied if HTML fragment is rendered and does not have an explicit font-family style. patch #17253. - Improved: Properly aligning the aggregate value, based on the column information. #2395
مباحث
- #statement and expression in c
- delegates
- delegate instance
- Func
- lambda expression
- lambda expression return type in c# 10
- captured value
- static lambda
- IEnumerable, IQueryable
- description of Expression Tree
- Writing Expression Tree
- Where and Order by and ... Decorator
- Chaining decorator
- Query Execution
- Inside of IQueryable
- Expression Visitor
سعی کردم کدهام و با SecondLevelCash به صورت Reactor اصلاح کنم اما یکی از موارد پر کاربرد گرفتند Count از Iqueryble است .
موقع Count گرفتن Linq به دستورات Sql مواردی اضافه می‌کند و نمی‌توان Count را کش کرد.
برای این دست موارد باید دستی Query کانت جنریت بشه و یا راه حل دیگه ای دارد؟
با سلام؛ من زمانی که این کد را در SQl 2012 میکنم یک Error در خصوص ToGregorianTime() نمایش داده میشه. لطفا راهنمایی بفرمایید. با تشکر
Msg 6522, Level 16, State 2, Line 1 A .NET Framework error occurred during execution of user-defined routine or aggregate "SpatialDateTime": System.FormatException: String was not recognized as a valid DateTime. System.FormatException: at System.DateTimeParse.ParseExactMultiple(String s, String[] formats, DateTimeFormatInfo dtfi, DateTimeStyles style) at System.DateTime.ParseExact(String s, String[] formats, IFormatProvider provider, DateTimeStyles style) at System.Data.SqlTypes.SqlDateTime.Parse(String s) at SpatialDateTime.ToGregorianTime().
مطلبی که در ذیل آورده شده صرفا یک برداشت شخصی است بر اساس نقل قول‌ها و بررسی وضعیت اعضای تیم‌های مرتبط با فناوری‌های مختلف بکار گرفته شده در دات نت فریم ورک و ... نه رسمی!
ADO.NET ، DataSet ، DataTable و امثال آن: مرده! (مرده به معنای اینکه دیگر توسعه‌ی جدی نخواهد یافت)
ADO.NET اولین فناوری دسترسی به داده‌ها در دات نت فریم ورک بود/است. مدل طراحی آن هم بر اساس امکانات زبان‌های آن زمان (زمان شروع به کار دات نت) بود (و تا دات نت 4 هم تغییر عمده‌ای نکرده). برای مثال در زمان ارائه اولین نگارش آن خبری از Generics نبود (در دات نت 2 اضافه شد)؛ یا LINQ وجود نداشت (در دات نت سه و سه و نیم اضافه و تکمیل شد). به همین جهت طراحی آن در حال حاضر (با وجود دات نت 4) بوی ماندگی می‌دهد (مانند استفاده از دیتاست و دیتاتیبل) و با ORM های مایکروسافت جهت استفاده از امکانات Generics و LINQ جایگزین شده است.
البته این مورد تنها مورد مرده‌ای است که "باید" یاد گرفت؛ مهم نیست که ORMs ارائه شده‌اند. مهم این است که زیر ساخت تمام ORM های نوشته شده برای دات نت همین ADO.NET خام است.
LINQ to SQL : مرده!
مایکروسافت با این فناوری ORM های خودش را شروع کرد اما بعد از مدتی دید که بهتر است یک نسخه‌ی عمومی‌تر با پشتیبانی از بانک‌های اطلاعاتی دیگر مانند اوراکل، MySQL و غیره را نیز ارائه دهد. همینجا بود که آن‌را خیلی ساده با Entity framework جایگزین کرد و در roadmap ارائه شده صراحتا EF به عنوان راه حل توصیه شده دسترسی به داده‌های مایکروسافت اعلام شده است (+). حالا این وسط دیگر مهم نیست شما پروژه نوشته بودید یا هر چی. دیگر منتظر تغییرات خاصی در LINQ to SQL نباشید. فقط یک سری رفع باگ و نگهداری پروژه را شاهد خواهید بود. البته در همان زمان خیلی زود تکذیب کردند که LINQ to SQL مرده اما برای نمونه آقای Damien که عضو اصلی تیم LINQ to SQL بودند، اکنون در تیم XBOX مشغول به کار هستند! (+) تو خود شرح مفصل بخوان از این مجمل!
ضمنا این رو هم در نظر داشته باشید که LINQ != LINQ to SQL ؛ به عبارتی LINQ به خودی خود فقط یک language feature است.
Windows Forms یا به اختصار WinForms : مرده!
به نظر مظلوم‌تر از این یکی در دات نت یافت نمی‌شود! همین چند وقت پیش یکی از اعضای مایکروسافت این نظر سنجی رو برگزار کرده بود که "ما چکار کنیم که شما راحت‌تر از WinForms به WPF مهاجرت کنید؟!" (+)
در قاموس WPF ، ویندوز فرمز یعنی Canvas panel ؛ به عبارتی صلب‌ترین حالت طراحی رابط کاربری و این انتقال و مهاجرت هرچند برای کسانی که عمری را روی آن گذاشته‌اند، دردناک خواهد بود اما با وجود توانایی‌های WPF چیزی را از دست نخواهند داد. سیستم Layout (طرح بندی) در WinForms و همچنین دلفی، بر اساس قراردهی اشیاء در مختصات مطلقی در صفحه است. مثلا این دکمه‌ی خاص در آن نقطه‌ی معلوم قرار می‌گیرد و همین. این روش طرح بندی یکی از چندین روش طرح بندی در WPF است که اصطلاحا Canvas نام دارد. توصیه اکید و مطلق در WPF آن است که از Canvas فقط برای طراحی اشیاء گرافیکی پیچیده استفاده کنید و نه طراحی رابط کاربر. چرا؟ چون برای مثال در Silverlight که برادر کوچکتر WPF محسوب می‌شود، رابط کاربری آن باید بتواند همانند HTML انعطاف پذیر باشد و با اندازه‌های مختلف مرورگر یا اندازه‌ی قلم‌های بزرگتر هماهنگ شده و مقاومت کند، بدون اینکه از ریخت بیفتد و این مورد را سایر سیستم‌های طرح بندی رابط کاربر (منهای Canvas یا همان سیستم طرح بندی WinForms) ارائه می‌دهند. مورد دیگری که در WPF و Silverlight بسیار حائز اهمیت است ، Content Controls می‌باشد. چقدر خوب می‌شد بتوان داخل یک کنترل، کلا یک سیستم طرح بندی را تعریف کرد و اشیاء دلخواهی را داخل آن قرار داد. مثلا ToolTip پیش فرض وجود دارد. بسیار هم خوب. بنده علاقه دارم، متن عنوان آن ضخیم باشد. کنار آن یک تصویر کوچک و در سمت چپ آن متن قرار گیرد. برای انجام اینکار در WPF لازم نیست تا شما منتظر نگارش بعدی دات نت باشید که دست اندرکاران مربوطه با افتخار در یک سند 50 صفحه‌ای توضیح دهند که چگونه می‌توان اینکار را انجام داد. یک سیستم طرح بندی را اضافه کنید. موارد ذکر شده را در آن تعریف کنید. بدون استفاده از هیچ نوع کامپوننتی یا بدون منتظر ماندن تا نگارش بعدی این محصولات، به مقصود خود رسیده‌اید.
ASP.NET Web forms : داره نفس‌های آخرش رو می‌کشه!
از زمانیکه ASP.NET MVC آمد نسخه‌ی Web forms تقریبا فراموش شد. به وبلاگ اسکات گاتری یا Haacked و سایر اعضای اصلی دات نت که مراجعه کنید در سه سال اخیر در حد تعداد انگشتان یک دست هم در مورد Web forms مطلب ننوشته‌اند. تمام تمرکز و نوآوری‌ها بر روی MVC متمرکز شده و حتی در نسخه‌ی 4 دات نت هم فقط یک سری صافکاری مختصر را در Web forms شاهد بودیم مثلا نام کنترل‌ها را خودتان هم در زمان رندر نهایی می‌توانید تعیین کنید! یا لطفا کردند و قسمتی از url routing موجود در ASP.NET MVC را به ASP.NET web forms 4 هم قرض دادند (این مورد شاید مهم‌ترین تغییر قابل ذکر در ASP.Net web forms 4 است).
البته این رو هم اضافه کنم که ASP.NET MVC واقعا قابل احترام است؛ هدف از آن جدا سازی لایه‌های برنامه با الگوهای استاندارد صنعتی (و نه هر روش برنامه نویسی چند لایه من درآوردی)، ترویج کد نویسی بهتر، ترویج Unit testing ، رفع یک سری مشکلات ASP.NET Web forms (مثلا از ViewState های حجیم دیگر خبری نیست) و امثال آن است.
برای نمونه توجه شما را به مطلبی که آقای Dino Sposito در مورد ASP.NET Webforms نوشته جلب میکنم: (+)
به صورت خلاصه ایشان عنوان کرده زمان طراحی ASP.NET Webforms در 10 سال قبل، هدف ما انتقال ساده‌تر برنامه نویس‌های VB به محیط وب بود. به همین جهت دست به اختراع postback ، viewState ، کنترل‌های سمت سرور و غیره زدیم. (بنابراین تاکید تمام این‌ها این است که webforms فناوری دهه قبل "بود" و الان بنابر نیازهای جدید دست به طراحی مجدد زده‌ایم)
در مورد "پایان پروژه ASP.NET Ajax Control Toolkit" هم قبلا مطلب نوشته بودم و این یکی واقعا official است!
و در پایان باید متذکر شد که فلان فناوری مرده یا داره نفس‌های آخرش رو می‌کشه اصلا مهم نیست. هنوز هم هستند سازمان‌هایی که برنامه‌های نوشته شده با ASP کلاسیک (نگارش قبل از ASP.NET Web forms) خود را دارند و خیلی هم از آن راضی هستند!
این موارد رو از این جهت نوشتم که اگر می‌خواهید تازه به این جمع وارد شوید دقیقا بدانید باید روی چه مواردی بیشتر وقت بگذارید و یادگیری کدامیک صرفا اتلاف وقت خواهند بود (مثلا EF بر LINQ to SQL ارجح است و اگر امروز می‌خواهید شروع کنید با EF شروع کنید، یا دیگر کم کم با وجود WPF ، بازار کاری برای WinForms نخواهد بود).
For TypeScript 2.0, the current road map consists of:
• Non-nullable types
• Control flow based typed analysis
• Async/await downlevel support
• Readonly properties
• Declared 'this' type in functions
• Improved typings acquisition
در حال حاضر انشعاب رسمی features پروژه‌ی Roslyn دارای این افزونه‌ها است که به احتمال زیاد به C# 7 اضافه خواهند شد:
features/Annotated Types features/Nullable Reference Types features/constVar features/local-functions features/multi-Var features/openGenericNameInNameof features/patterns features/privateprotected features/ref-returns features/tuples
یک نکته‌ی تکمیلی: اضافه شدن متد TryGetNonEnumeratedCount به دات نت 6
public static bool TryGetNonEnumeratedCount(this IEnumerable<T> source, out int count);
زمانیکه متد ()Count را بر روی یک <IEnumerable<T فراخوانی می‌کنیم، دو کار ممکن رخ می‌دهند:
الف) کتابخانه‌ی LINQ سعی می‌کند تا این نوع را به یکی از انواع مشتق شده‌ی از IEnumerable که دارای خاصیت Count است (مانند IList و امثال آن)، تبدیل کند تا بر این اساس بتواند به سرعت تعداد عناصر آن‌را تشخیص دهد.
ب) اگر حالت الف میسر نشد، تمام عناصر IEnumerable را جهت یافتن تعداد آن‌ها، پیمایش و شمارش می‌کند که این عملیات برای مجموعه‌های بزرگ می‌تواند بسیار زمانبر باشد.
اکنون در دات نت 6، حالت امن گزینه‌ی الف، با ارائه‌ی متد الحاقی جدید TryGetNonEnumeratedCount، میسر شده‌است. یعنی اگر مجموعه‌ی مدنظر به همراه خاصیت Count بود، بلافاصله از آن استفاده کرده و خروجی out آن‌را ارائه می‌دهد، در غیراینصورت false را بر می‌گرداند و مقدار count صفر خواهد بود؛ یعنی حالت ب را دیگر هیچگاه اجرا نخواهد کرد و به این ترتیب می‌توان به کنترل بیشتری بر روی API ارائه شده رسید.
if (movies.TryGetNonEnumeratedCount(out int count))
{
Console.WriteLine($"The count is {count}");
}
else
{
Console.WriteLine("Could not get a count of movies without enumerating the collection");
}