اشتراک‌ها
نگارش‌های آتی ReSharper و Rider نیاز به نصب حداقل NET Framework 4.7.2. را دارند

Starting with the 2021.2 releases of our .NET productivity tools, including ReSharper and Rider (on Windows), we will require .NET Framework 4.7.2 or newer installed on your machine. Earlier versions of our .NET tools will continue to work on .NET Framework 4.6.1. 

نگارش‌های آتی ReSharper و Rider نیاز به نصب حداقل NET Framework 4.7.2. را دارند
اشتراک‌ها
تامین هویت مرکزی به کمک keycloak در برنامه‌های Web API
.NET Web API with Keycloak

In this article, we will explore the advantages of using Keycloak, an open-source identity and access management solution. With Keycloak, you can easily add authentication and authorization to your applications, benefiting from the robustness of a proven system instead of building your own. This allows you to avoid the complexities and security challenges of managing application access control on your own.
تامین هویت مرکزی به کمک keycloak در برنامه‌های Web API
اشتراک‌ها
سری آموزشی Bash Scripting در لینوکس

Bash Scripting on Linux

The Bash Scripting Essentials series will teach you everything you need to know in order to write effective bash scripts in Linux. The series starts with some introductory concepts, with each episode building on the last. By the end of this series, you'll be able to write your own bash scripts! The Bash Scripting series was one of the very first tutorial series on Learn Linux TV ever, so it's basically where it all started. Now, it's been remade and brought into the modern age. The new version of this series covers everything the original version did, with additional concepts added throughout.

سری آموزشی Bash Scripting در لینوکس
مطالب
بلاگ‌ها و مطالب مطالعه شده در هفته قبل (هفته سوم آبان)

وبلاگ‌ها و سایت‌های ایرانی


ASP. Net


طراحی وب


به روز رسانی‌ها


ابزارها


سی‌شارپ


عمومی دات نت


دلفی



ویندوز


متفرقه

  • کدام سایت‌ها مطالب شما را کپی کرده‌اند؟! (البته شبیه به این کار را با Google alerts هم می‌شود انجام داد. فقط کافی است آدرس سایت خودتان را در گوگل alert اضافه کنید. هر جایی لینکی به شما داده شود یا امثال آن، یک ایمیل آنی یا روزانه بسته به تنظیمات برای شما ارسال خواهد کرد.)


مطالب
مهارت‌های تزریق وابستگی‌ها در برنامه‌های NET Core. - قسمت یازدهم - پیاده سازی پویای Decoratorها توسط Castle.Core
در قسمت قبل، نحوه‌ی پیاده سازی الگوی Decorator را با استفاده از امکانات تزریق وابستگی‌های NET Core. بررسی کردیم؛ اما ... این روزها کسی Decoratorها را دستی ایجاد نمی‌کند. یعنی اگر قرار باشد به ازای هر کلاسی و هر سرویسی، یکبار کلاس Decorator آن‌را با پیاده سازی همان اینترفیس سرویس اصلی و فراخوانی دستی تک تک متدهای سرویس اصلی تزریق شده‌ی در سازنده‌ی آن انجام دهیم، آنچنان کاربردی به نظر نمی‌رسد. به همین منظور کتابخانه‌هایی تحت عنوان Dynamic Proxy تهیه شده‌اند تا کار ساخت و پیاده سازی پویای Decorator‌ها را انجام دهند. در این بین ما فقط منطق برای مثال مدیریت استثناءها، لاگ کردن ورودی‌ها و خروجی‌های متدها، کش کردن خروجی متدها، سعی مجدد اجرای متدهای با شکست مواجه شده و ... تک تک متدهای یک سرویس را به آن‌ها معرفی می‌کنیم و سپس پروکسی‌های پویا، کار محصور سازی خودکار اشیاء ساخته شده‌ی از سرویس اصلی را برای ما انجام می‌دهند. این روش نه فقط کار نوشتن دستی Decorator کلاس‌ها را حذف می‌کند، بلکه عمومی‌تر نیز بوده و به تمام سرویس‌ها قابل اعمال است.


Interceptors پایه‌ی پروکسی‌های پویا هستند

برای پیاده سازی پروکسی‌های پویا نیاز است با مفهوم Interceptors آشنا شویم. به کمک Interceptors فرآیند فراخوانی متدها و خواص یک کلاس، تحت کنترل و نظارت قرار خواهند گرفت. زمانیکه یک IOC Container کار وهله سازی کلاس سرویس خاصی را انجام می‌دهد، در همین حین می‌توان مراحل شروع، پایان و خطاهای متدها یا فراخوانی‌های خواص را نیز تحت نظر قرار داد و به این ترتیب مصرف کننده، امکان تزریق کدهایی را در این مکان‌ها خواهد یافت. مزیت مهم استفاده از Interceptors، عدم نیاز به کامپایل ثانویه اسمبلی‌های موجود، برای تغییری در کدهای آن‌ها است (برای تزریق نواحی تحت کنترل قرار دادن اعمال) و تمام کارها به صورت خودکار در زمان اجرای برنامه مدیریت می‌گردند.

با اضافه کردن Interception به پروسه وهله سازی سرویس‌ها توسط یک IoC Container، مراحل کار اینبار به صورت زیر تغییر می‌کنند:
الف) در اینجا نیز در ابتدا فراخوان، درخواست وهله‌ای را بر اساس اینترفیسی خاص، به IOC Container ارائه می‌دهد.
ب) IOC Container نیز سعی در وهله سازی درخواست رسیده را بر اساس تنظیمات اولیه‌ی خود می‌کند.
ج) اما در این حالت IOC Container تشخیص می‌دهد نوعی که باید بازگشت دهد، علاوه بر وهله سازی، نیاز به مزین سازی و پیاده سازی Interceptors را نیز دارد. بنابراین نوع مورد انتظار را در صورت وجود، به یک Dynamic Proxy، بجای بازگشت مستقیم به فراخوان ارائه می‌دهد.
د) در  ادامه Dynamic Proxy، نوع مورد انتظار را توسط Interceptors محصور کرده و به فراخوان بازگشت می‌دهد.
ه) اکنون فراخوان، در حین استفاده از امکانات شیء وهله سازی شده، به صورت خودکار مراحل مختلف اجرای یک Decorator را سبب خواهد شد.

یعنی به صورت خلاصه، فراخوان سرویسی را درخواست می‌دهد، اما وهله‌ای را که دریافت می‌کند، یک لایه‌ی اضافه‌تر تزئین کننده را نیز به همراه دارد که کاملا از دید فراخوان مخفی است و نحوه‌ی کار کردن با آن سرویس، با و بدون این تزئین کننده، دقیقا یکی است. وجود این لایه‌ی تزئین کننده سبب می‌شود تا فراخوانی هر متد این سرویس، از این لایه گذشته و سبب اجرای یک سری کد سفارشی، پیش و پس از اجرای این متد نیز گردد.


پیاده سازی پروکسی‌های پویا توسط کتابخانه‌ی Castle.Core در برنامه‌های NET Core.

در ادامه از کتابخانه‌ی بسیار معروف Castle.Core برای پیاده سازی پروکسی‌های پویا استفاده خواهیم کرد. از این کتابخانه در پروژه‌ی EF Core، برای پیاده سازی Lazy loading نیز استفاده شده‌است.
برای دریافت آن یکی از دستورات زیر را اجرا نمائید:
> Install-Package Castle.Core
> dotnet add package Castle.Core
و یا به صورت خلاصه برای افزودن آن، فایل csproj برنامه به صورت زیر تغییر می‌کند:
<Project Sdk="Microsoft.NET.Sdk.Web">
  <ItemGroup>
    <PackageReference Include="castle.core" Version="4.3.1" />
  </ItemGroup>
</Project>


تبدیل ExceptionHandlingDecorator مثال قسمت قبل، به یک Interceptor مخصوص Castle.Core

در قسمت قبل، کلاس MyTaskServiceDecorator را جهت اعمال یک try/catch به همراه logging، به متد Run سرویس MyTaskService، تهیه کردیم. در اینجا قصد داریم نگارش عمومی‌تر این تزئین کننده را با طراحی یک Interceptor مخصوص Castle.Core انجام دهیم:
using System;
using Castle.DynamicProxy;
using Microsoft.Extensions.Logging;

namespace CoreIocSample02.Utils
{
    public class ExceptionHandlingInterceptor : IInterceptor
    {
        private readonly ILogger<ExceptionHandlingInterceptor> _logger;

        public ExceptionHandlingInterceptor(ILogger<ExceptionHandlingInterceptor> logger)
        {
            _logger = logger;
        }

        public void Intercept(IInvocation invocation)
        {
            try
            {
                invocation.Proceed(); //فراخوانی متد اصلی در اینجا صورت می‌گیرد
            }
            catch (Exception ex)
            {
                _logger.LogCritical(ex, "An unhandled exception has been occurred.");
            }
        }
    }
}
برای تهیه‌ی یک کلاس Interceptor، کار با پیاده سازی اینترفیس IInterceptor شروع می‌شود. در اینجا فراخوانی متد ()invocation.Proceed، دقیقا معادل فراخوانی متد اصلی سرویس است؛ شبیه به کاری که در قسمت قبل انجام دادیم:
        public void Run()
        {
            try
            {
                _decorated.Run();
            }
            catch (Exception ex)
            {
                _logger.LogCritical(ex, "An unhandled exception has been occurred.");
            }
        }
فراخوان، یک نمونه‌ی تزئین شده‌ی از سرویس درخواستی را دریافت می‌کند. زمانیکه متد Run این نمونه‌ی ویژه را اجرا می‌کند، در حقیقت وارد متد Run این Decorator شده‌است که اینبار در پشت صحنه، توسط Dynamic proxy ما به صورت پویا ایجاد می‌شود. اکنون جائیکه ()invocation.Proceed فراخوانی می‌شود، دقیقا معادل همان ()decorated.Run_ قسمت قبل است؛ یا همان اجرای متد اصلی سرویس مدنظر. اینجا است که می‌توان منطق‌های سفارشی را مانند لاگ کردن، کش کردن، سعی مجدد در اجرا و بسیاری از حالات دیگر، پیاده سازی کرد.


اتصال ExceptionHandlingInterceptor تهیه شده به سیستم تزریق وابستگی‌ها

در ادامه روش معرفی ExceptionHandlingInterceptor تهیه شده را به سیستم تزریق وابستگی‌ها، توسط متد Decorate کتابخانه‌ی Scrutor که آن‌را در قسمت قبل بررسی کردیم، ملاحظه می‌کنید:
namespace CoreIocSample02
{
    public class Startup
    {
        private static readonly ProxyGenerator _dynamicProxy = new ProxyGenerator();

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddTransient<ITaskService, MyTaskService>();
            services.AddTransient<ExceptionHandlingInterceptor>();
            services.Decorate(typeof(ITaskService),
             (target, serviceProvider) =>
                _dynamicProxy.CreateInterfaceProxyWithTargetInterface(
                  interfaceToProxy: typeof(ITaskService),
                  target: target,
                  interceptors: serviceProvider.GetRequiredService<ExceptionHandlingInterceptor>())
            );
- ProxyGenerator به همین نحو static readonly باید تعریف شود و در کل برنامه یک وهله از آن مورد نیاز است.
- سپس نیاز است خود سرویس اصلی غیر تزئین شده، به نحو متداولی به سیستم معرفی شود.
- در ادامه توسط متد الحاقی Decorate، کار تزئین ITaskService را با یک dynamicProxy که ExceptionHandlingInterceptor را به صورت پویا تبدیل به یک Decorator کرده و بر روی تک تک متدهای سرویس ITaskService اجرا می‌کند، انجام می‌دهیم.
- کاری که Scrutor در اینجا انجام می‌دهد، یافتن سرویس ITaskService معرفی شده‌ی پیشین و تعویض آن با dynamicProxy می‌باشد. بنابراین نیاز است تعریف services.AddTransient، پیش از تعریف services.Decorate انجام شده باشد.

یک نکته: چون ExceptionHandlingInterceptor دارای پارامتر تزریق شده‌ای در سازنده‌ی آن است، بهتر است خود آن‌را نیز به صورت یک سرویس ثبت کنیم و سپس وهله‌ای از آن‌را از طریق serviceProvider.GetRequiredService در قسمت interceptors متد CreateInterfaceProxyWithTargetInterface معرفی کنیم تا نیازی به مقدار دهی دستی تک تک پارامترهای سازنده‌ی آن نباشد.

اکنون اگر برنامه را اجرا کنیم و برای مثال ITaskService را در سازنده‌ی یک کنترلر تزریق کنیم، بجای دریافت وهله‌ای از کلاس MyTaskService، اینبار وهله‌ای از Castle.Proxies.ITaskServiceProxy را دریافت می‌کنیم.


به این معنا که Castle.Core به صورت پویا وهله‌ی سرویس MyTaskService را داخل یک Castle.Proxies پیچیده‌است و از این پس ما از طریق این واسط، با سرویس اصلی MyTaskService ارتباط برقرار خواهیم کرد. برای درک بهتر این مراحل، بر روی سازنده‌ی کلاس کنترلر و همچنین متد Intercept، تعدادی break-point را قرار دهید.
اشتراک‌ها
روش صحیح استفاده از ASP.NET Identity، بدون وابستگی Domain و سایر لایه ها به آن

The Problem

What they neglect to say is all that testability and persistence ignorance flies right out the window when you create a new ASP.NET Web Application using the MVC template and "Individual User Accounts" authentication. What you get is a single-layered application, tightly coupled to Entity Framework, that:

  • Ignores the patterns that facilitate testing, including: the repository pattern, unit of work pattern, and dependency injection;

  • Forces you to implement their IUser interface in your application’s User entity, thereby coupling it to ASP.NET Identity;

  • Eliminates any clear separation between your entities, persistence concerns, and business logic. Persistence ignorance? Forget about it.

Thankfully, due to the extensibility designed into ASP.NET Identity, it is possible to ditch the reference to the Microsoft.AspNet.Identity.EntityFramework assembly and write a custom implementation that can address these and other architectural issues. Just be forewarned: it is not a trivial undertaking, and you’ll have to put up with some code smell that is baked into the Microsoft.AspNet.Identity.Core assembly. 

روش صحیح استفاده از ASP.NET Identity، بدون وابستگی Domain و سایر لایه ها به آن
نظرات مطالب
افزودن یک DataType جدید برای نگه‌داری تاریخ خورشیدی - 1
سلام
کدهای شمارو درست همونطوریکه گفتین کپی کردم ولی موقعی که Publish رو میزنم پیغام زیر رو میده :
Publish cannot begin until your project(s) build successfully
و پنجره publish ظاهر نمی‌شه و هیچ جایی هم برای تعریف کانکشن وجود نداره... مشکل از کجاست؟
دوم اینکه clr رو هربار که خواستیم روی یک دیتابیس جدید این نوع رو تعریف کنیم باید فعال کنیم... مثلا توی ایجاد سال مالی جدید که سیستم یک دیتابیس خام ایجاد میکنه تا مانده حسابها رو بهش انتقال بدیم قبلش باید دستور فعال سازی clr رو هم مجددا بدیم یافقط توی زمان طراحی کفایت میکنه ؟
سوم اینکه : در مورد استفاده اون توی EF Code First هم اگه نکته‌ی خاصی وجود داره محبت کنین ممنون میشم.
شاد وپیروز باشید.
اشتراک‌ها
سری بررسی NET Aspire.

.NET Aspire Developers Day

15 videos

Are you ready to take your .NET development skills to the next level? We are thrilled to announce .NET Aspire Developers Day, a unique livestream event happening on July 23, 2024. Whether you're an experienced .NET developer or just getting started with .NET Aspire, this event is designed to equip you with advanced knowledge, practical skills, and insights from industry experts.

سری بررسی NET Aspire.
مطالب
مدیریت مرکزی شماره نگارش‌های بسته‌های NuGet در پروژه‌های NET Core.
عموما برنامه‌های بزرگ NET.، به چندین زیر پروژه شکسته می‌شوند تا مدیریت آن‌ها ساده‌تر شود. مهم‌ترین مشکلی که در این حالت پس از مدتی بروز می‌کند، هماهنگ نگه داشتن شماره نگارش‌های ارجاعات NuGet این پروژه‌ها است و همچنین به روز رسانی مکرر و هر باره‌ی تمام این فایل‌های csproj. به همین جهت ایده‌ی مدیریت مرکزی شماره نگارش‌های ارجاعات پروژه‌های NuGet قرار است به نگارش بعدی آن اضافه شود که البته هم اکنون نیز قسمتی از آن در NET Core SDK 3.1.300. به بعد، قابل استفاده‌است که جزئیات آن‌را در ادامه مرور می‌کنیم.


ایجاد فایل جدید Directory.Packages.props

زمانیکه قرار است شماره نگارش‌های بسته‌های NuGet مختلف مورد استفاده‌ی در برنامه، به صورت مرکزی مدیریت شوند، نیاز به یک مخزن ثبت آن‌ها نیز می‌باشد. به همین جهت یک فایل جدید را به نام Directory.Packages.props در کنار فایل sln پروژه‌ی خود ایجاد کنید (در ریشه‌ی اصلی پروژه)؛ با این محتوای فرضی:
<Project>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" />
    <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" />
  </ItemGroup>
</Project>
برای تشکیل این فایل، فایل‌های csproj مختلف موجود در solution جاری را یافته و سپس PackageReference‌های آن‌ها را به فایل props فوق کپی کنید؛ با یک تفاوت مهم: بجای PackageReference اینبار از نام PackageVersion استفاده می‌شود.


تغییرات مورد نیاز در فایل‌های پروژه‌های موجود

در ادامه مجددا به تمام فایل‌های csproj خود مراجعه کرده و ویژگی Version را از آن‌ها حذف کنید؛ مانند:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Localization.Abstractions" />
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" />
  </ItemGroup>
</Project>
 از این پس دیگر هیچکدام از فایل‌های پروژه‌ی شما نباید به همراه قید صریح شماره نگارش بسته‌های مورد استفاده باشند؛ در غیر اینصورت در حین Build پروژه، خطای زیر را دریافت خواهید کرد:
error NU1008: Projects that use central package version management should not define the version on the PackageReference items

همچنین اگر دقت کرده باشید، ویژگی جدید ManagePackageVersionsCentrally نیز به این فایل پروژه و سایر فایل‌های پروژه نیز باید اضافه شود. حالت پیش‌فرض آن false است.

یک نکته: می‌توان ویژگی ManagePackageVersionsCentrally را نیز به صورت سراسری به فایل Directory.Packages.props اضافه کرد تا به صورت خودکار به تمام فایل‌های csproj موجود، اعمال شود:
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" />
    <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" />
  </ItemGroup>
</Project>


نحوه‌ی افزودن بسته‌های جدید

قابلیتی که تا اینجا معرفی شد، در NET Core SDK 3.1.300. به بعد قابل دسترسی و استفاده‌است (و پس از این تغییرات، برنامه بدون مشکل کامپایل می‌شود)؛ اما هنوز NET Core CLI. برای افزودن خودکار بسته‌های جدید NuGet به این سیستم، به روز رسانی نشده‌است. یعنی فعلا اگر خواستید بسته‌ی جدیدی را اضافه کنید باید ابتدا به صورت دستی PackageVersion آن‌را در فایل Directory.Packages.props ثبت کنید و سپس PackageReference بدون شماره‌ی نگارش را نیز به پروژه‌ی مدنظر خود به صورت دستی اضافه کنید.



برای مطالعه بیشتر
مستندات رسمی آن
وضعیت پیاده سازی آن