اشتراکها
نظرات مطالب
ساخت بستههای نیوگت مخصوص NET Core.
به روز رسانی
با حذف فایل project.json در VS 2017، اکنون با کلیک راست بر روی گروه نام پروژه (فایل csproj)، گزینهی Edit آن ظاهر شده و مداخل ذکر شدهی در مطلب فوق، چنین تعاریفی را پیدا میکنند:
برای تولید مستندات و کنترل اخطارهای آن:
و اگر خواستید دات نت 4.6 یا فریم ورکهای دیگر را نیز پشتیبانی کنید، ItemGroupهای آنها به این صورت اضافه میشوند:
با حذف فایل project.json در VS 2017، اکنون با کلیک راست بر روی گروه نام پروژه (فایل csproj)، گزینهی Edit آن ظاهر شده و مداخل ذکر شدهی در مطلب فوق، چنین تعاریفی را پیدا میکنند:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <Description>desc.</Description> <VersionPrefix>1.0.0</VersionPrefix> <Authors>name</Authors> <TargetFramework>netstandard1.6</TargetFramework> <GenerateDocumentationFile>true</GenerateDocumentationFile> <AssemblyName>name</AssemblyName> <PackageId>name</PackageId> <PackageTags>MVC;aspnetcore</PackageTags> <PackageProjectUrl>https://github.com/proj</PackageProjectUrl> <PackageLicenseUrl>https://github.com/proj/blob/master/LICENSE.md</PackageLicenseUrl> <PackageTargetFallback>$(PackageTargetFallback);dnxcore50</PackageTargetFallback> <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute> <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute> <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.2" /> </ItemGroup> <PropertyGroup Condition=" '$(Configuration)' == 'Release' "> <PlatformTarget>anycpu</PlatformTarget> </PropertyGroup> <Target Name="PostcompileScript" AfterTargets="Build"> <Exec Command="dotnet pack --no-build --configuration $(Configuration)" /> </Target> </Project>
<PropertyGroup> <NoWarn>$(NoWarn);1591</NoWarn> <GenerateDocumentationFile>true</GenerateDocumentationFile> </PropertyGroup>
<PropertyGroup> <TargetFrameworks>net46;netstandard1.3</TargetFrameworks> </PropertyGroup> <ItemGroup Condition=" '$(TargetFramework)' == 'net46' "> <Reference Include="System" /> <Reference Include="System.Core" /> </ItemGroup> <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.3' "> <PackageReference Include="System.Data.Common" Version="4.3.0" /> </ItemGroup>
فرض کنید میخواهید زمانیکه دکمهی build در VS.NET فشرده شد، دو نسخهی دات نت 4 و دات نت 4.5، از پروژهی شما در پوشههای مجزایی کامپایل شده و قرار گیرند. در ادامه نحوهی انجام اینکار را بررسی خواهیم کرد.
پروژه نمونه
تنظیمات ذیل را بر روی یک پروژه از نوع class library دات نت 4 در VS 2013 اعمال خواهیم کرد.
ویرایش فایل پروژه برنامه
برای اینکه تنظیمات کامپایل خودکار مخصوص دات نت 4.5 را نیز به این پروژه دات نت 4 اضافه کنیم، نیاز است فایل csproj آنرا مستقیما ویرایش نمائیم. این تغییرات شامل مراحل ذیل هستند:
الف) تعریف متغیر Framework
به ابتدای فایل csproj در قسمت PropertyGroup آن یک متغیر جدید را به نام Framework اضافه کنید. از این متغیر در شرطهای کامپایل استفاده خواهد شد.
ب) ویرایش مسیر خروجی تنظیمات کامپایل فعلی
در حال حاضر حداقل تنظیمات کامپایل حالت debug، در فایل پروژه موجود است. مقدار OutputPath آنرا به نحو فوق تغییر دهید تا خروجی نهایی را در پوشهای مانند bin\Debug\NET40 ایجاد کند.
بدیهی است اگر حالت release هم وجود دارد، نیاز است مقدار OutputPath آنرا نیز به همین ترتیب ویرایش کرد.
ج) افزودن تنظیمات کامپایل دات نت 4.5 به پروژه جاری
در اینجا تنظیمات حالت debug و release مخصوص دات نت 4.5 را مشاهده میکنید. برای نگارشهای دیگر، تنها کافی است مقدار TargetFrameworkVersion را ویرایش کنید.
همچنین اگر به DefineConstants آن دقت کنید، مقدار NET45 نیز به آن اضافه شدهاست. این مورد سبب میشود که بتوانید در پروژهی جاری، شرطیهایی را ایجاد کنید که کدهای آن فقط در حین کامپایل برای دات نت 4.5 به خروجی اسمبلی نهایی اضافه شوند:
د) افزودن تنظیمات پس از build
در انتهای فایل csproj قسمت AfterBuild به صورت کامنت شده موجود است. آنرا به نحو ذیل تغییر دهید:
این تنظیم سبب میشود تا کامپایل مخصوص دات نت 4.5 نیز به صورت خودکار فعال گردد و خروجی آن در مسیر bin\Debug\NET45 به صورت جداگانهای قرار گیرد.
برای آزمایش بیشتر، فایل csproj نهایی را از اینجا میتوانید دریافت کنید:
DualTargetFrameworks.zip
پروژه نمونه
تنظیمات ذیل را بر روی یک پروژه از نوع class library دات نت 4 در VS 2013 اعمال خواهیم کرد.
ویرایش فایل پروژه برنامه
برای اینکه تنظیمات کامپایل خودکار مخصوص دات نت 4.5 را نیز به این پروژه دات نت 4 اضافه کنیم، نیاز است فایل csproj آنرا مستقیما ویرایش نمائیم. این تغییرات شامل مراحل ذیل هستند:
الف) تعریف متغیر Framework
<PropertyGroup> <!-- ...--> <Framework Condition=" '$(Framework)' == '' ">NET40</Framework> </PropertyGroup>
ب) ویرایش مسیر خروجی تنظیمات کامپایل فعلی
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> <!-- ...--> <OutputPath>bin\$(Configuration)\$(Framework)\</OutputPath> </PropertyGroup>
بدیهی است اگر حالت release هم وجود دارد، نیاز است مقدار OutputPath آنرا نیز به همین ترتیب ویرایش کرد.
ج) افزودن تنظیمات کامپایل دات نت 4.5 به پروژه جاری
<PropertyGroup Condition=" '$(Framework)' == 'NET45' And '$(Configuration)|$(Platform)' == 'Debug|AnyCPU'"> <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> <PlatformTarget>AnyCPU</PlatformTarget> <DebugSymbols>true</DebugSymbols> <DebugType>full</DebugType> <Optimize>false</Optimize> <OutputPath>bin\$(Configuration)\$(Framework)\</OutputPath> <DefineConstants>DEBUG;TRACE;NET45</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> </PropertyGroup> <PropertyGroup Condition=" '$(Framework)' == 'NET45' And '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> <PlatformTarget>AnyCPU</PlatformTarget> <DebugType>pdbonly</DebugType> <Optimize>true</Optimize> <OutputPath>bin\$(Configuration)\$(Framework)\</OutputPath> <DefineConstants>TRACE;NET45</DefineConstants> <ErrorReport>prompt</ErrorReport> <WarningLevel>4</WarningLevel> </PropertyGroup>
همچنین اگر به DefineConstants آن دقت کنید، مقدار NET45 نیز به آن اضافه شدهاست. این مورد سبب میشود که بتوانید در پروژهی جاری، شرطیهایی را ایجاد کنید که کدهای آن فقط در حین کامپایل برای دات نت 4.5 به خروجی اسمبلی نهایی اضافه شوند:
#if NET45 public class ExtensionAttribute : Attribute { } #endif
د) افزودن تنظیمات پس از build
در انتهای فایل csproj قسمت AfterBuild به صورت کامنت شده موجود است. آنرا به نحو ذیل تغییر دهید:
<Target Name="AfterBuild"> <Message Text="Enter After Build TargetFrameworkVersion:$(TargetFrameworkVersion) Framework:$(Framework)" Importance="high" /> <MSBuild Condition=" '$(Framework)' != 'NET45'" Projects="$(MSBuildProjectFile)" Properties="Framework=NET45" RunEachTargetSeparately="true" /> <Message Text="Exiting After Build TargetFrameworkVersion:$(TargetFrameworkVersion) Framework:$(Framework)" Importance="high" /> </Target>
برای آزمایش بیشتر، فایل csproj نهایی را از اینجا میتوانید دریافت کنید:
DualTargetFrameworks.zip
C# 7.1 به همراه به روز رسانی سوم VS 2017 ارائه شدهاست و اگر در ابتدای کار سعی کنید برای مثال یکی از ویژگیهای جدید C# 7.1، مانند static async Task Main را توسط آن آزمایش کنید، خطای کامپایل برنامه را دریافت میکنید. علت اینجا است که این نگارش خاص حتما نیاز به تنظیمات ویژهای را جهت فعالسازی دارد.
فعالسازی کامپایلر C# 7.1 در VS 2017
ابتدا مسیر Visual Studio -> Build tab -> Advanced را طی کنید:
پس از کلیک بر روی دکمهی Advanced، نیاز است C# 7.1 را انتخاب نمائید:
سؤال: چرا چنین مشکلی با نگارشهای پیشین زبان سیشارپ در ویژوال استودیو وجود نداشت؟
تابحال زبان سیشارپ نگارش minor نداشتهاست. همانطور که در تصویر فوق ملاحظه میکنید، گزینهی پیشفرض زبان مورد استفاده بر روی C# latest major version قرار دارد. این گزینه به معنای انتخاب نگارش 7.0، در این لیست است و نه 7.1. در اینجا major به نگارش 7.0 اشاره میکند و یا نگارشهای 8.0، 9.0 و پس از آن (در صورت ارائه و نصب به روز رسانیها). به همین جهت است که نمیتوان برای مثال static async Task Main را به صورت پیش فرض و با اعمال آخرین به روز رسانیها کامپایل کرد. برای رفع این مشکل یا میتوان برای مثال C# 7.1 را مستقیما انتخاب کرد و یا میتوان «C# latest minor version» را انتخاب کرد که این مورد گزینهی بهتری است نسبت به حالت C# latest major version و دقیقا به C# 7.1 و یا نگارشهای پس از آن اشاره میکند.
انتخاب زبان در پروژههای NET Core.
روش فوق با تمام نگارشهای NET. کار میکند. اما با توجه به اینکه یک چنین گزینههایی برای مثال در VSCode وجود ندارند و یا برنامههای NET Core. را میتوان صرفا از طریق خط فرمان، ایجاد، کامپایل و اجرا کرد، در این نوع پروژهها برای انتخاب زبان باید به صورت ذیل عمل نمود:
در اینجا گزینهی LangVersion را یا میتوان به 7.1 تنظیم کرد و یا بهتر است مقدار آنرا مساوی latest قرار داد تا همواره به آخرین کامپایلر نصب شدهی توسط SDK اشاره کند.
فعالسازی کامپایلر C# 7.1 در VS 2017
ابتدا مسیر Visual Studio -> Build tab -> Advanced را طی کنید:
پس از کلیک بر روی دکمهی Advanced، نیاز است C# 7.1 را انتخاب نمائید:
سؤال: چرا چنین مشکلی با نگارشهای پیشین زبان سیشارپ در ویژوال استودیو وجود نداشت؟
تابحال زبان سیشارپ نگارش minor نداشتهاست. همانطور که در تصویر فوق ملاحظه میکنید، گزینهی پیشفرض زبان مورد استفاده بر روی C# latest major version قرار دارد. این گزینه به معنای انتخاب نگارش 7.0، در این لیست است و نه 7.1. در اینجا major به نگارش 7.0 اشاره میکند و یا نگارشهای 8.0، 9.0 و پس از آن (در صورت ارائه و نصب به روز رسانیها). به همین جهت است که نمیتوان برای مثال static async Task Main را به صورت پیش فرض و با اعمال آخرین به روز رسانیها کامپایل کرد. برای رفع این مشکل یا میتوان برای مثال C# 7.1 را مستقیما انتخاب کرد و یا میتوان «C# latest minor version» را انتخاب کرد که این مورد گزینهی بهتری است نسبت به حالت C# latest major version و دقیقا به C# 7.1 و یا نگارشهای پس از آن اشاره میکند.
انتخاب زبان در پروژههای NET Core.
روش فوق با تمام نگارشهای NET. کار میکند. اما با توجه به اینکه یک چنین گزینههایی برای مثال در VSCode وجود ندارند و یا برنامههای NET Core. را میتوان صرفا از طریق خط فرمان، ایجاد، کامپایل و اجرا کرد، در این نوع پروژهها برای انتخاب زبان باید به صورت ذیل عمل نمود:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> </PropertyGroup> <PropertyGroup> <LangVersion>latest</LangVersion> <!-- <LangVersion>7.1</LangVersion> --> </PropertyGroup> </Project>
ممنون. من از این کتابخانه استفاده میکنم:
Yahoo! UI Library: YUI Compressor for .Net
نحوه استفاده از اون رو باکدنویسی در بالا ملاحظه میکنید (ملاحظات utf8 و زبان فارسی هم در آن لحاظ شده).
کاری که هنگام ارائه نهایی انجام میدم، اسکن فایلهای نهایی و بررسی پسوندها و سپس استفاده از متد Compress فوق روی فایلهای اسکریپت و css یافت شده است.
Yahoo! UI Library: YUI Compressor for .Net
using System.Globalization; using System.IO; using System.Text; using Yahoo.Yui.Compressor; namespace Deploy.Core { public static class CompressCssJs { public static void Compress(string file) { var ext = Path.GetExtension(file).ToLower(); switch (ext) { case ".css": compressCss(file); break; case ".js": if (!file.ToLower().EndsWith(".min.js") && !file.ToLower().EndsWith(".pack.js")) compressJs(file); break; } } static void compressCss(string file) { var css = File.ReadAllText(file); var compressedCss = new CssCompressor().Compress(css); File.WriteAllText(file, compressedCss, Encoding.UTF8); } static void compressJs(string file) { var js = File.ReadAllText(file); var compressedJavaScript = new JavaScriptCompressor { CompressionType = CompressionType.Standard, DisableOptimizations = false, Encoding = Encoding.UTF8, LineBreakPosition = -1, ObfuscateJavascript = true, PreserveAllSemicolons = false, ThreadCulture = CultureInfo.CurrentUICulture, IgnoreEval = false, LoggingType = LoggingType.None }.Compress(js); File.WriteAllText(file, compressedJavaScript, Encoding.UTF8); } } }
کاری که هنگام ارائه نهایی انجام میدم، اسکن فایلهای نهایی و بررسی پسوندها و سپس استفاده از متد Compress فوق روی فایلهای اسکریپت و css یافت شده است.
طی این مقاله، نحوهی ذخیره سازی تنظیمات متغیر و پویای یک برنامه را به صورت Strongly Typed ارائه خواهم داد. برای این منظور، یک API را که از Lazy Loading ، Cache ، Reflection و Entity Framework بهره میگیرد، خواهیم ساخت.
برنامهی هدف ما که از این API استفاده میکند، یک اپلیکیشن Asp.net MVC است. قبل از شروع به ساخت API مورد نظر، یک دید کلی در مورد آنچه که قرار است در نهایت توسعه یابد، در زیر مشاهده میکنید:
public SettingsController(ISettings settings) { // example of saving _settings.General.SiteName = "دات نت تیپس"; _settings.Seo.HomeMetaTitle = ".Net Tips"; _settings.Seo.HomeMetaKeywords = "َAsp.net MVC,Entity Framework,Reflection"; _settings.Seo.HomeMetaDescription = "ذخیره تنظیمات برنامه"; _settings.Save(); }
همانطور که در کدهای بالا مشاهده میکنید، شی setting_ ما دارای دو پراپرتی فقط خواندنی بنامهای General و Seo است که شامل تنظیمات مورد نظر ما هستند و این دو کلاس از کلاس پایهی SettingBase ارث بری کردهاند. دو دلیل برای انجام این کار وجود دارد:
- تنظیمات به صورت گروه بندی شده در کنار هم قرار گرفتهاند و یافتن تنظیمات برای زمانی که نیاز به دسترسی به آنها داریم، راحتتر و سادهتر خواهد بود.
- به این شکل تنظیمات قابل دسترس در یک گروه، از دیتابیس بازیابی خواهند شد.
اصلا چرا باید این تنظیمات را در دیتابیس ذخیره کنیم؟
شاید فکر کنید چرا باید تنظیمات را در دیتابیس ذخیره کنیم در حالی که فایل web.config در درسترس است و میتوان توسط کلاس ConfigurationManager به اطلاعات آن دسترسی داشت.
جواب: دلیل این است که با تغییر فایل web.config، برنامهی وب شما ری استارت خواهد شد (چه زمانهایی یک برنامه Asp.net ری استارت میشود).
برای جلوگیری از این مساله، راه حل مناسب برای ذخیره سازی اطلاعاتی که نیاز به تغییر در زمان اجرا دارند، استفاده از از دیتابیس میباشد. در این مقاله از Entity Framework و پایگاه داده Sql Sever استفاده میکنم.
مراحل ساخت Setting API مورد نظر به شرح زیر است:
- ساخت یک Asp.net Web Application
- ساخت مدل Setting و افزودن آن به کانتکست Entity Framework
- ساخت کلاس SettingBase برای بازیابی و ذخیره سازی تنظیمات با رفلکشن
- ساخت کلاس GenralSettins و SeoSettings که از کلاس SettingBase ارث بری کردهاند.
- ساخت کلاس Settings به منظور مدیریت تمام انواع تنظیمات
یک برنامهی Asp.Net Web Application را از نوع MVC ایجاد کنید. تا اینجا مرحلهی اول ما به پایان رسید؛ چرا که ویژوال استودیو کارهای مورد نیاز ما را انجام خواهد داد.
لازم است مدل خود را به ApplicationDbContext موجود در فایل IdentityModels.cs معرفی کنیم. به شکل زیر:
namespace DynamicSettingAPI.Models { public interface IUnitOfWork { DbSet<Setting> Settings { get; set; } int SaveChanges(); } } public class ApplicationDbContext : IdentityDbContext<ApplicationUser>,IUnitOfWork { public DbSet<Setting> Settings { get; set; } public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } } namespace DynamicSettingAPI.Models { public class Setting { public string Name { get; set; } public string Type { get; set; } public string Value { get; set; } } }
لازم است تا متد OnModelCreating مربوط به ApplicationDbContext را نیز تحریف کنیم تا کانفیگ مربوط به مدل خود را نیز اعمال نمائیم.
protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity<Setting>() .HasKey(x => new { x.Name, x.Type }); modelBuilder.Entity<Setting>() .Property(x => x.Value) .IsOptional(); base.OnModelCreating(modelBuilder); }
ساختاری به شکل زیر مد نظر ماست:
کلاس SettingBase ما همچین ساختاری را خواهد داشت:
namespace DynamicSettingAPI.Service { public abstract class SettingsBase { //1 private readonly string _name; private readonly PropertyInfo[] _properties; protected SettingsBase() { //2 var type = GetType(); _name = type.Name; _properties = type.GetProperties(); } public virtual void Load(IUnitOfWork unitOfWork) { //3 get setting for this type name var settings = unitOfWork.Settings.Where(w => w.Type == _name).ToList(); foreach (var propertyInfo in _properties) { //get the setting from setting list var setting = settings.SingleOrDefault(s => s.Name == propertyInfo.Name); if (setting != null) { //4 set propertyInfo.SetValue(this, Convert.ChangeType(setting.Value, propertyInfo.PropertyType)); } } } public virtual void Save(IUnitOfWork unitOfWork) { //5 get all setting for this type name var settings = unitOfWork.Settings.Where(w => w.Type == _name).ToList(); foreach (var propertyInfo in _properties) { var propertyValue = propertyInfo.GetValue(this, null); var value = (propertyValue == null) ? null : propertyValue.ToString(); var setting = settings.SingleOrDefault(s => s.Name == propertyInfo.Name); if (setting != null) { // 6 update existing value setting.Value = value; } else { // 7 create new setting var newSetting = new Setting() { Name = propertyInfo.Name, Type = _name, Value = value, }; unitOfWork.Settings.Add(newSetting); } } } } }
متد Load وظیفهی واکشی تمام تنظیمات مربوط به Type و ست کردن مقادیر به دست آمده را به خصوصیات کلاس ما، برعهده دارد. کد زیر مقدار دریافتی از دیتابیس را به نوع داده پراپرتی مورد نظر تبدیل کرده و نتیجه را به عنوان Value پراپرتی ست میکند.
propertyInfo.SetValue(this, Convert.ChangeType(setting.Value, propertyInfo.PropertyType));
متد Save نیز وظیفهی ذخیره سازی مقادیر موجود در خصوصیات کلاس تنظیماتی را که از کلاس SettingBase ما به ارث برده است، به عهده دارد.
این متد دیتاهای موجود دردیتابیس را که متعلق به کلاس ارث برده مورد نظر ما هستند، واکشی میکند و در یک حلقه، اگر خصوصیتی در دیتابیس موجود بود، آن را ویرایش کرده وگرنه یک رکورد جدید را ثبت میکند.
کلاسهای تنظیمات شخصی سازی شده خود را به شکل زیر تعریف میکنیم :
public class GeneralSettings : SettingsBase { public string SiteName { get; set; } public string AdminEmail { get; set; } public bool RegisterUsersEnabled { get; set; } } public class GeneralSettings : SettingsBase { public string SiteName { get; set; } public string AdminEmail { get; set; } }
برای اینکه تنظیمات را به صورت یکجا داشته باشیم و Abstraction ای را برای استفاده از این API ارائه دهیم، یک اینترفیس و یک کلاس که اینترفیس مذکور را پیاده کرده است در نظر میگیریم:
public interface ISettings { GeneralSettings General { get; } SeoSettings Seo { get; } void Save(); } public class Settings : ISettings { // 1 private readonly Lazy<GeneralSettings> _generalSettings; // 2 public GeneralSettings General { get { return _generalSettings.Value; } } private readonly Lazy<SeoSettings> _seoSettings; public SeoSettings Seo { get { return _seoSettings.Value; } } private readonly IUnitOfWork _unitOfWork; public Settings(IUnitOfWork unitOfWork) { _unitOfWork = unitOfWork; // 3 _generalSettings = new Lazy<GeneralSettings>(CreateSettings<GeneralSettings>); _seoSettings = new Lazy<SeoSettings>(CreateSettings<SeoSettings>); } public void Save() { // only save changes to settings that have been loaded if (_generalSettings.IsValueCreated) _generalSettings.Value.Save(_unitOfWork); if (_seoSettings.IsValueCreated) _seoSettings.Value.Save(_unitOfWork); _unitOfWork.SaveChanges(); } // 4 private T CreateSettings<T>() where T : SettingsBase, new() { var settings = new T(); settings.Load(_unitOfWork); return settings; } }
این اینترفیس مشخص میکند که ما به چه نوع تنظیماتی، دسترسی داریم و متد Save آن برای آپدیت کردن تنظیمات، در نظر گرفته شده است. هر کلاسی که از کلاس SettingBase ارث بری کرده را به صورت فیلد فقط خواندنی و با استفاده از کلاس Lazy درون آن ذکر میکنیم و به این صورت کلاس تنظیمات ما زمانی ساخته خواهد شد که برای اولین بار به آن دسترسی داشته باشیم.
متد CreateSetting وظیفهی لود دیتا را از دیتابیس، بر عهده دارد که برای این منظور، متد لود Type مورد نظر را فراخوانی میکند. این متد وقتی به کلاس تنظیمات مورد نظر برای اولین بار دسترسی پیدا کنیم، فراخوانی خواهد شد.
حتما امکان این وجود دارد که شما از امکان Caching هم بهره ببرید برای مثال همچین متد و سازندهای را در کلاس Settings در نظر بگیرید:
private readonly ICache _cache; public Settings(IUnitOfWork unitOfWork, ICache cache) { // ARGUMENT CHECKING SKIPPED FOR BREVITY _unitOfWork = unitOfWork; _cache = cache; _generalSettings = new Lazy<GeneralSettings>(CreateSettingsWithCache<GeneralSettings>); _seoSettings = new Lazy<SeoSettings>(CreateSettingsWithCache<SeoSettings>); } private T CreateSettingsWithCache<T>() where T : SettingsBase, new() { // this is where you would implement loading from ICache throw new NotImplementedException(); }
public ActionResult Index() { using (var uow = new ApplicationDbContext()) { var _settings = new Settings(uow); _settings.General.SiteName = "دات نت تیپس"; _settings.General.AdminEmail = "admin@gmail.com"; _settings.General.RegisterUsersEnabled = true; _settings.Seo.HomeMetaTitle = ".Net Tips"; _settings.Seo.MetaKeywords = "Asp.net MVC,Entity Framework,Reflection"; _settings.Seo.HomeMetaDescription = "ذخیره تنظیمات برنامه"; var settings2 = new Settings(uow); var output = string.Format("SiteName: {0} HomeMetaDescription: {1} MetaKeywords: {2} MetaTitle: {3} RegisterEnable: {4}", settings2.General.SiteName, settings2.Seo.HomeMetaDescription, settings2.Seo.MetaKeywords, settings2.Seo.HomeMetaTitle, settings2.General.RegisterUsersEnabled.ToString() ); return Content(output); } }
نکته: در پروژه ای که جدیدا در سایت ارائه دادهام و در حال تکمیل آن هستم، از بهبود یافتهی این مقاله استفاده میشود. حتی برای اسلاید شوهای سایت هم میشود از این روش استفاده کرد و از فرمت json بهره برد برای این منظور. حتما در پروژهی مذکور همچین امکانی را هم در نظر خواهم گرفتم.
پیشنها میکنم سورس SmartStore را بررسی کنید. آن هم به شکل مشابهی ولی پیشرفتهتر از این مقاله، همچین امکانی را دارد.
با استفاده از Blazor میتوان برنامههای وب تعاملی را با کمک زبان #C تهیه کرد که پیشتر برای نوشتن آنها به جاوا اسکریپت نیاز بود. به این ترتیب میتوان برای تهیهی قسمتهای front-end و backend پروژهی خود، از زبانی که به آن تسلط دارید استفاده کنید. یکی از مزایای آن امکان به اشتراک گذاری کدهای سمت سرور و کلاینت است؛ با توجه به اینکه هر دو به یک زبان تهیه میشوند.
وضعیت توسعهی برنامههای وب، پیش از ارائهی Blazor
عموما برای توسعهی برنامههای وب، در سمت سرور آنها از زبانهایی مانند C#، Java و Python و امثال آنها استفاده میشود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریمورکها و کتابخانههای جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده میشود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبانها، مشکل و وقتگیر است. بنابراین چقدر خوب میشد اگر امکان تهیهی هر دو قسمت برنامههای وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شدهاست.
با استفاده از Blazor میتوان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان میتوان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه میتوان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالتهای مختلف هاست و ارائهی برنامههای مبتنی بر Blazor
برنامههای مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامهی استاندارد ASP.NET Core است که در آن تمام قابلیتهای سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچهای در سراسر برنامه وجود دارد. در این حالت، کامپوننتهای Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانیهای UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننتهای Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنهی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده میگیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامهی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا میشود. به Blazor web assembly باید همانند فریمورکهای SPA (تک صفحهای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامهی SPA، از #C استفاده میشود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامههای Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار میگیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی میشود؛ منهای IE 11. در این حالت مرورگر کل برنامهی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامهی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا میشود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوریها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورکهای SPA، نیاز به تهیهی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالتهای مختلف هاست برنامههای Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانههای سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامههای سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجهی نهایی رندر شده، به سمت کلاینت بازگشت داده میشود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمیتوان از برنامه استفاده کرد.
- با توجه به نیاز به استفادهی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامهها کمتر است. البته اگر تعداد کاربران برنامههای شما در یک شبکهی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامهی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائهی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت میشود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفادهی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت میشود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامههای SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژههای خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژهی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
بنابراین فقط کافی است دستور dotnet new blazorserver و یا dotnet new blazorwasm را در یک پوشهی خالی اجرا کنیم تا بر اساس قالبهای پیشفرض ارائه شده، بتوان پروژههای خالی Blazor Server و یا Blazor WebAssembly را ایجاد کرد.
در قسمت بعد، این دو پروژهی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوهی هاست این برنامهها عنوان شد، بر روی این پروژهها مشاهده خواهیم کرد.
وضعیت توسعهی برنامههای وب، پیش از ارائهی Blazor
عموما برای توسعهی برنامههای وب، در سمت سرور آنها از زبانهایی مانند C#، Java و Python و امثال آنها استفاده میشود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریمورکها و کتابخانههای جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده میشود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبانها، مشکل و وقتگیر است. بنابراین چقدر خوب میشد اگر امکان تهیهی هر دو قسمت برنامههای وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شدهاست.
با استفاده از Blazor میتوان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان میتوان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه میتوان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالتهای مختلف هاست و ارائهی برنامههای مبتنی بر Blazor
برنامههای مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامهی استاندارد ASP.NET Core است که در آن تمام قابلیتهای سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچهای در سراسر برنامه وجود دارد. در این حالت، کامپوننتهای Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانیهای UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننتهای Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنهی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده میگیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامهی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا میشود. به Blazor web assembly باید همانند فریمورکهای SPA (تک صفحهای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامهی SPA، از #C استفاده میشود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامههای Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار میگیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی میشود؛ منهای IE 11. در این حالت مرورگر کل برنامهی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامهی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا میشود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوریها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورکهای SPA، نیاز به تهیهی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالتهای مختلف هاست برنامههای Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانههای سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامههای سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجهی نهایی رندر شده، به سمت کلاینت بازگشت داده میشود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمیتوان از برنامه استفاده کرد.
- با توجه به نیاز به استفادهی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامهها کمتر است. البته اگر تعداد کاربران برنامههای شما در یک شبکهی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامهی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائهی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت میشود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفادهی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت میشود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامههای SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژههای خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژهی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
C:\Users\Vahid>dotnet new --list Templates Short Name Language Tags -------------------------------------------- ------------------- ------------ ---------------------- Blazor Server App blazorserver [C#] Web/Blazor Blazor WebAssembly App blazorwasm [C#] Web/Blazor/WebAssembly
در قسمت بعد، این دو پروژهی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوهی هاست این برنامهها عنوان شد، بر روی این پروژهها مشاهده خواهیم کرد.
Rust – the Ultimate Programming Language?
What makes a good programming language? Syntax? Compiler? Tools and ecosystem? It is tempting to say “all of that” but in that case, why there are so many different programming languages? All these components are very important but they alone can’t make the language “good”. One of essential things is the purpose — like languages for rapid development, or development of distributed algorithms, or general purpose for high-level and low-level applications, or easy to learn, or safe to use and so on.
- TLS 1.0: The request was aborted: Could not create SSL/TLS secure channel.
- Task List with filter set to Entire Solution doesnt display tasks/todos when the file is closed.
- Fatal error C1001: An internal error has occurred in the compiler.
- VS 2019 Preview 1 - EF6 edmx file cannot be saved.
- vcruntime140.dll should be made available on Microsoft Symbol Server.
- Static Analyser, Custom Rule Set (C++) does not execute included default sets.
- VS2019 Preview: Azure Function publishing does not work.
- References window does not remember its position.
- Missing formatting option for pointers and references.
- Microsoft.TeamFoundation.Client, Version=15.0.0.0 assembly not found when create a new web project.
- امکان سنجی پروژههای نرمافزاری | | blog.fardapardaz.com
- لینوکس نیازی به آنتی ویروس نداره... | www.negahbaan.com
- پول ویندوز را بدهیم یا ندهیم؟ | (Afshar Mohebbi) | blog.afsharm.com
- دولت آلمان استفاده از بدافزار جاسوسی را تایید کرد | فرهاد جعفری | www.winbeta.net
- زبان برنامه نویسی جدید گوگل : دارت | (مجتبی بنائی) | www.banaie.ir
- گوگل زبان جدید برنامه نویسی را با نام Dart معرفی کرد | www.zoomit.ir
- وضعیت اینترنت پرسرعت پس از رفع محدودیت حجمی | علی پارسا | www.winbeta.net
- EF 4.2 RC منتشر شد | blogs.msdn.com
- Microsoft Security Intelligence Report | www.microsoft.com
- TortoiseSVN-1.7.0 منتشر شد | sourceforge.net
- استفاده از Direct3D 11 در دات نت | blogs.msdn.com
- بررسی EF 4.2 در حالت اول دیتابیس | blogs.msdn.com
- بررسی تازههای EF 4.2 | blogs.msdn.com
- جلوگیری از CSRF حین استفاده از Ajax | feeds.haacked.com
- دات نت 4 و نیم و کاهش ری استارت سیستم در حین نصب آن | channel9.msdn.com
- در مورد سایت جدید ASP.NET نظر دهید | weblogs.asp.net
- دسترسی به MSDN به کمک وب سرویسهای آن | msdn.microsoft.com