اشتراک‌ها
پروژه Piranha CMS

Piranha CMS - The Open source CMS for .NET Core, NetStandard and AspNetCore MVC 

پروژه Piranha CMS
اشتراک‌ها
ده قابلیت ASP.NET Core برای توسعه دهندگان ASP.NET MVC

ASP.NET Core 1.0 (formerly ASP.NET 5) provides a revamped Web development framework geared towards the requirements of modern Web applications. The new framework, currently in RC1, requires you to learn many new concepts not found in ASP.NET MVC 5. To that end, this article enumerates a few important features that ASP.NET MVC 5 developers should know as they prepare to learn this new framework. 

ده  قابلیت  ASP.NET Core  برای توسعه دهندگان ASP.NET MVC
اشتراک‌ها
CleanArchitecture-Template
پیاده سازی معماری تمیز در asp.net core با استفاده از تاپ‌ترین تکنولوژی‌ها و رعایت اصول کدنویسی و معماری نرم افزار


: Technologies used
 ASP.NET Core
 Entity Framework Core
 CQRS
MediatR
 Swagger
 Api Versioning
 FluentValidation
 Serilog
 Elasticsearch(for writing Logs)
 AutoMapper

: Software Development Best Practices used
 Clean Architecture
 Clean Code
 Solid Principles
 REST API Naming Conventions
 Use multiple environments in ASP.NET Core(Development,Production,Staging,etc)
 Modular Design
 Custom Exceptions
 Custom Exception Handling
 PipelineBehavior for Validation and Performance tracking
CleanArchitecture-Template
نظرات مطالب
یکپارچه سازی Angular CLI و ASP.NET Core در VS 2017
مرحله
معادل آن در پروژه‌های قدیمی MVC 5
  ایجاد یک پروژه‌ی جدید ASP.NET Core در VS 2017  
 یک پروژه‌ی جدید Web API را ایجاد کنید. 
  تنظیمات یک برنامه‌ی ASP.NET Core خالی برای اجرای یک برنامه‌ی Angular CLI  
 به این موارد نیازی نخواهید داشت. چون پروژه‌های MVC 5 برخلاف ASP.NET Core، پوشه‌هایی را که دستی به آن اضافه نکنید، به صورت خودکار به پروژه اضافه نمی‌کند. بنابراین فایل‌های Angular-CLI را به Solution Explorer وارد نکنید و بهترین روش کار کردن با آن‌ها از طریق VSCode است. در اینجا برای back-end (کار با Web API) از VS کامل استفاده کنید و برای front-end از VSCode. 
  افزودن یک کنترلر Web API جدید  
 کلیات آن با MVC 5 یکی است. 
  تنظیمات فایل آغازین یک برنامه‌ی ASP.NET Core جهت ارائه‌ی برنامه‌های Angular  
 معادل قسمت URL Rewrite آن، از نکته‌ی web.config مطلب «مسیریابی در Angular - قسمت اول - معرفی»، قسمت «تفاوت بین آدرس‌های HTML 5 و Hash-based» استفاده کنید. 
  ایجاد ساختار اولیه‌ی برنامه‌ی Angular CLI در داخل پروژه‌ی جاری
 یکی هست. 
  تنظیم محل خروجی نهایی Angular CLI به پوشه‌ی wwwroot  
 یکی هست. فقط شاید علاقمند باشید مسیر "" (پوشه‌ی ریشه) را بجای wwwroot تنظیم کنید. 
 فراخوانی کنترلر Web API برنامه در برنامه‌ی Angular CLI  
 یکی هست. 
  نصب وابستگی‌های برنامه‌ی Angular CLI  
 یکی هست. 
  روش اول اجرای برنامه‌های مبتنی بر ASP.NET Core و Angular CLI  
 یکی هست. 
  روش دوم اجرای برنامه‌های مبتنی بر ASP.NET Core و Angular CLI  
 در اینجا نیازی به آن نیست ولی در کل مطالعه‌ی نکات آن مفید است.
 فایل‌های bat ارائه شده و یا روش NPM Task Runner در نظرات   یکی هستند. 
نظرات مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 15 - بررسی تغییرات Caching
فیلتر Authorize هم در ASP.NET Core هدرهای مربوط به کش کردن را بازنویسی و تنظیم می‌کند. به عبارتی صفحه‌ای که از این فیلتر رد شود، فقط دارای "CacheControl = "no-cache خواهد بود (تا به اشتباه اینگونه صفحات دارای سطح دسترسی، کش نشوند؛ موردی که در نگارش قبلی ASP.NET MVC به صورت توکار بررسی نمی‌شد).
نظرات مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 10 - بررسی تغییرات Viewها
با سلام و احترام
آیا در این روش استفاده از Area به این شکل صحیح است ؟
public IEnumerable<string> ExpandViewLocations(ViewLocationExpanderContext context, IEnumerable<string> viewLocations)
        {
            // {0} - Action Name
            // {1} - Controller Name
            // {2} - Area Name

            if (context.ActionContext.RouteData.Values.TryGetValue("area", out _))
            {
                return new[]
                {
                    "/Areas/{2}/Features/{1}/{0}.cshtml",
                    "/Areas/{2}/Features/Shared/{0}.cshtml",
                    "/Features/Shared/{0}.cshtml"
                };
            }
            else
            {
                return new[]
                {
                    "/Features/{1}/{0}.cshtml",
                    "/Features/Shared/{0}.cshtml"
                };
            }
        }
و یا باید کلا Area را به زیر مجموعه فولدر Features واقع در Root پروژه منتقل کرد که البته این حالت در مورد Area‌های کوچک توصیه شد ولی در حالتی که Area دارای کنترل‌های بسیار است استانداردی مشخص نیست.
قطعه کد بالا برداشت بنده از لینک زیر است:
ASP.NET Core - Feature Slices for ASP.NET Core MVC  
نظرات مطالب
الگوی استراتژی - Strategy Pattern
تفاوت مهمی نداره؛ فقط اینترفیس ورژن پذیر نیست. یعنی اگر در این بین متدی رو به تعاریف اینترفیس خودتون اضافه کردید، تمام استفاده کننده‌ها مجبور هستند اون رو پیاده سازی کنند. اما کلاس Abstract می‌تونه شامل یک پیاده سازی پیش فرض متد خاصی هم باشه و به همین جهت ورژن پذیری بهتری داره.
بنابراین کلاس Abstact یک اینترفیس است که می‌تواند پیاده سازی هم داشته باشد.
همین مساله خاص نگارش پذیری، در طراحی ASP.NET MVC به کار گرفته شده: (^ )
برای من نوعی شاید این مساله اهمیتی نداشته باشه. اگر من قرارداد اینترفیس کتابخانه خودم را تغییر دادم، بالاخره شما با یک حداقل نق زدن مجبور به به روز رسانی کار خودتان خواهید شد. اما اگر مایکروسافت چنین کاری را انجام دهد، هزاران نفر شروع خواهند کرد به بد گفتن از نحوه مدیریت پروژه تیم‌های مایکروسافت و اینکه چرا پروژه جدید آن‌ها با یک نگارش جدید MVC کامپایل نمی‌شود. بنابراین انتخاب بین این دو بستگی دارد به تعداد کاربر پروژه شما و استراتژی ورژن پذیری قرار دادهای کتابخانه‌ای که ارائه می‌دهید.