Claim Based Identity
تولید پویای ستونها در PdfReport
تمام مباحث و مفاهیم آن یکی است. فقط قسمت منبع داده آن نیاز است تغییر کند:
.MainTableDataSource(dataSource => { dataSource.SqlDataReader(...
> ng test --help
یک مثال: بررسی اجرای دستور ng test
یکی از مثالهای بررسی شدهی در این سری را انتخاب و یا حتی یک برنامهی جدید را توسط Angular CLI ایجاد کرده و سپس دستور ng test را در ریشهی این پروژه اجرا کنید. به این ترتیب برنامه به صورت خودکار کامپایل شده و سپس به صورت خودکار آزمونهای واحد آنرا که در فایلهای spec.ts.* قرار دارند، اجرا میکند. در آخر نتیجه را در مرورگر گزارش میدهد:
همانطور که مشخص است، 3 specs, 3 failures داریم. در اینجا میتوان بر روی لینک Spec List کلیک کرد و لیست آزمونهای واحد موجود را مشاهده نمود:
هر کدام از عناوین ذکر شده نیز به جزئیات مشکلات آنها، لینک شدهاند. برای مثال اگر بر روی اولین مورد کلیک کنیم، خطایی مانند «'alert' is not a known element» قابل مشاهدهاست. به این معنا که برای نمونه در قسمت قبل کامپوننت alert را به صفحه اضافه کردیم:
<alert type="success">Alert success!</alert>
import { NO_ERRORS_SCHEMA } from '@angular/core'; describe('AppComponent', () => { beforeEach(async(() => { TestBed.configureTestingModule({ declarations: [ AppComponent ], schemas: [NO_ERRORS_SCHEMA] }).compileComponents(); }));
پس از این تغییر، بلافاصله مجدد برنامه کامپایل شده و آزمونهای واحد آن با موفقیت اجرا میشوند (با این فرض که هنوز پنجرهی اجرا کنندهی دستور ng test را باز نگه داشتهاید):
تغییر افزودن schemas: [NO_ERRORS_SCHEMA] را باید در مورد تمام فایلهای spec موجود تکرار کرد.
گزینههای مختلف دستور ng test
دستور ng test به همراه گزینههای متعددی است که شرح آنها را در جدول ذیل مشاهده میکنید:
گزینه | مخفف | توضیح |
code-coverage-- | cc- | تولید گزارش code coverage که به صورت پیش فرض خاموش است. |
colors-- | به صورت پیش فرض فعال است و سبب نمایش رنگهای قرمز و سبز، برای آزمونهای شکست خورده و یا موفق میشود. | |
single-run-- | sr- | اجرای یکبارهی آزمونهای واحد، بدون فعال سازی گزینهی مشاهدهی مداوم تغییرات که به صورت پیش فرض خاموش است. |
progress-- | نمایش جزئیات کامپایل و اجرای آزمونهای واحد که به صورت پیش فرض فعال است. | |
sourcemaps-- | sm- | تولید فایلهای سورسمپ که به صورت پیش فرض فعال است. |
watch-- | w- | بررسی مداوم تغییرات فایلها و اجرای آزمونهای واحد به صورت خودکار که به صورت پیش فرض فعال است. |
بنابراین اجرا دستور ng test بدون ذکر هیچ گزینهای به معنای اجرای مداوم آزمونهای واحد، در صورت مشاهدهی تغییراتی در آنها، به کمک Karma است.
همچنین دو دستور ذیل نیز به یک معنا هستند و هر دو سبب یکبار اجرای آزمونهای واحد میشوند:
> ng test -sr > ng test -w false
اجرای بررسی میزان پوشش آزمونهای واحد
یکی از گزینههای ng test روشن کردن پرچم code-coverage است:
> ng test --code-coverage
> ng test -sr -cc
کار این آزمون بررسی قسمتهای مختلف برنامه و ارائه گزارشی است که مشخص میکند آیا آزمونهای واحد نوشته شده تمام انشعابات برنامه را پوشش میدهند یا خیر؟ برای مثال اگر در متدی if/else دارید، آیا فقط قسمت if را پوشش دادهاید و یا آیا قسمت else هم در آزمونهای واحد، بررسی شدهاست.
اجرای آزمونهای end to end
هدف از ساخت یک برنامه ... استفادهی از آن توسط دیگران است؛ اینجا است که آزمونهای end to end مفهوم پیدا میکنند. در آزمونهای e2e رفتار برنامه همانند حالتی که یک کاربر از آن استفاده میکند، بررسی میشود (برای مثال باز کردن مرورگر، لاگین و مرور صفحات). برای این منظور، Angular CLI در پشت صحنه از Protractor برای این نوع آزمونها استفاده میکند.
برای مشاهدهی راهنما و گزینههای مختلف مرتبط با آزمونهای e2e، میتوان دستور ذیل را صادر کرد:
>ng e2e --help
گزینه | مخفف | توضیح |
config-- | c- | به فایل کانفیگ آزمونهای e2e اشاره میکند که به صورت پیشفرض همان protractor.conf.js واقع در ریشهی پروژهاست. |
element-explorer-- | ee- | بررسی و دیباگ protractor از طریق خط فرمان |
serve-- | s- | کامپایل و توزیع برنامه بر روی پورتی اتفاقی (حالت پیش فرض آن true است) |
specs-- | sp- | پیش فرض آن بررسی تمام specهای موجود در پروژهاست. اگر نیاز به لغو آن باشد میتوان از این گزینه استفاده کرد. |
webdriver-update-- | wu- |
به روز رسانی web driver که به صورت پیش فرض فعال است. |
بنابراین زمانیکه دستور ng e2e صادر میشود، به معنای کامپایل، توزیع برنامه بر روی پورتی اتفاقی و اجرای آزمونها است.
از این جهت که این نوع آزمونها، وابستهی به جزئی خاص از برنامه نیستند، حالت عمومی داشته و فایلهای spec آنها را میتوان در پوشهی e2e واقع در ریشهی پروژه، یافت. برای مثال در قسمتی از آن کار یافتن متن نمایش داده شدهی در صفحهی اول سایت انجام میشود
getParagraphText() { return element(by.css('app-root h1')).getText(); }
expect(page.getParagraphText()).toEqual('app works!');
برای آزمایش آن دستور ng e2e را در ریشهی پروژه صادر کنید. همچنین دقت داشته باشید که در این حالت نیاز است به اینترنت نیز متصل باشد؛ چون از chromedriver api گوگل نیز استفاده میکند. در غیراینصورت خطای ذیل را دریافت خواهید کرد:
Error: getaddrinfo ENOTFOUND chromedriver.storage.googleapis.com chromedriver.storage.googleapis.com:443
کتاب آموزش زبان برنامه نویسی Erlang
سخت افزارهای جدید به طور فزاینده ای همروند (parallel) شده اند، بنابراین زبانهای برنامه نویسی باید از همزمانی پشتیبانی کنند یا محکوم به مرگ هستند. نقل قولی از استیو جابز: راهی که شرکتهای ساخت پردازشگر در پیش گرفته اند این هست که هستههای بیشتر و بیشتر اضافه کنند، اما کسی نمیداند که چگونه برای آنها برنامه بنویسید. منظورم دو، بله؛ چهار، نه واقعا؛ هشت؛ کلا فراموشش کنید.
خب استیو اشتباه میکرده است؛ الان ما میدانیم که چگونه برای پردازشگرهای چند هسته ای برنامه بنویسیم. ما برنامه هایمان را با Erlang مینویسیم و هرچقدر که بر تعداد هستهها افزوده شود برنامهی ما نیز سریعتر از قبل کار میکند.
Erlang از همان ابتدا برای برنامه نویسی سیستمهای همزمان، توزیع پذیر، تحمل پذیر بودن خطا (fault-tolerant)، مقیاس پذیر (scalable)، نرم و بلادرنگ طراحی شده بود. سیستمهای نرم بلادرنگ به مانند سیستمهای ارتباطات تلفنی، سیستمهای بانکی و ... که در آنها تعدا دفعات پاسخ گویی سریع بسیار با اهمیت است. سیستمهای مبتنی بر Erlang در مقیاس عظیمی مستقر شده اند و بخشهای قابل توجهی از شبکه ارتباطات تلفن همراه دنیا را کنترل میکنند.
اگر مشکل شما همزمانی هست، اگر در حال ساخت سیستم چند کاربره هستید و یا اگر در حال ساخت سیستمی هستید که با زمان سرو کار دارد، استفاده از Erlang میتواند بخش زیادی از کارهای شما را کم کند، چرا که Erlang فقط برای ساخت چنین سیستمهای طراحی شده است.
استفاده از StructureMap به عنوان یک IoC Container
ممنون از را حلی که ارائه دادین، اشکال مربوطه رفع شد... مهندس جان حین اجرای برنامه و بدون استفاده از StructureMap حین اجرای برنامه کانکشن استرینگ رو تغییر میدم و از دیتابیسی به دیتابیس دیگه ای میرم و با تغییر متغییر و پارامتر مورد نظر کاملا جواب میده ولی وقتی با استفاده از StructureMap و روشی که فرمودین عمل میکنم اجازه سوئیچ روی دیتابیس دیگه رو نمیده وتغییری هم درکانکشن استرینگ جدید ارسال شده به Context مربوطه مشاهده نمیشه . کاربر حتما نیاز به تغییر سال عملیاتی حین اجرای برنامه و یا دسترسی به اطلاعات سال عملیاتی همتا رو بدون خروج از سال عملیاتی جاری داره....
این error رو میده :
The changes to the database were committed successfully, but an error occurred while updating the object context. The ObjectContext might be in an inconsistent state. Inner exception message: A referential integrity constraint violation occurred: The property values that define the referential constraints are not consistent between principal and dependent objects in the relationship.
- قسمت اول - نیاز به تامین کنندهی هویت مرکزی
- قسمت دوم - ایجاد ساختار اولیه
- قسمت سوم - بررسی مفاهیم OpenID Connect
- قسمت چهارم - نصب و راه اندازی IdentityServer
- قسمت پنجم - پیاده سازی ورود و خروج از سیستم
- قسمت ششم - کار با User Claims
- قسمت هفتم- امن سازی Web API
- قسمت هشتم- تعریف سطوح دسترسی پیچیده
- قسمت نهم- مدیریت طول عمر توکنها
- قسمت دهم- ذخیره سازی اطلاعات کاربران IDP در بانک اطلاعاتی
- قسمت یازدهم- استفاده از تامین کنندههای هویت خارجی
- قسمت دوازدهم- یکپارچه سازی با اکانت گوگل
- قسمت سیزدهم- فعالسازی اعتبارسنجی دو مرحلهای
- قسمت چهاردهم- آماده شدن برای انتشار برنامه
شما برای کار با دیتا در اندروید، کدامیک از روش های زیر را استفاده میکنید یا ترجیح می دهید؟
چگونگی رسیدگی به Null property در AutoMapper
با سلام
مهندس من یه دیتابیس دارم که حاوی اطلاعات است در جداول اون در تمام ستونها به غیر از ستون کلید اومده تیک alow null رو فعال کرده یعنی این ستونها میتونه مقدار null رو بگیره .
حالا اون برنامه که این اطلاعات رو وارد دیتابیس کرده اومده هر ستونی که نوعش رشته بوده مقدار empty وارد کرده نه null و ستون هایی که نوعشون int هست مقدار صفر وارد کرده , مثل همین مطلبی که شما گفتید اما به صورت سنتی .
به نظر شما من باید همین رویه رو با روش شما انجام بدم یا نه همون مقدار null و در دیتابیس ذخیره کنم ؟
ایجاد پروژههای خالی Blazor
در انتهای قسمت قبل، با روش ایجاد پروژههای خالی Blazor به کمک NET SDK 5x. آشنا شدیم. به همین جهت دو پوشهی جدید BlazorWasmSample و BlazorServerSample را ایجاد کرده و از طریق خط فرمان و با کمک NET CLI.، در پوشهی اولی دستور dotnet new blazorwasm و در پوشهی دومی دستور dotnet new blazorserver را اجرا میکنیم.
البته اجرای این دو دستور، نیاز به اتصال به اینترنت را هم برای بار اول دارند؛ تا فایلهای مورد نیاز و بستههای مرتبط را دریافت و restore کنند. بسته به سرعت اینترنت، حداقل یک ربعی را باید صبر کنید تا دریافت ابتدایی بستههای مرتبط به پایان برسد. برای دفعات بعدی، از کش محلی NuGet، برای restore بستههای blazor استفاده میشود که بسیار سریع است.
بررسی ساختار پروژهی Blazor Server و اجرای آن
پس از اجرای دستور dotnet new blazorserver در یک پوشهی خالی و ایجاد پروژهی ابتدایی آن:
همانطور که مشاهده میکنید، ساختار این پروژه، بسیار شبیه به یک پروژهی استاندارد ASP.NET Core از نوع Razor pages است.
- در پوشهی properties آن، فایل launchSettings.json قرار دارد که برای نمونه، شماره پورت اجرایی برنامه را در حالت اجرای توسط دستور dotnet run و یا توسط IIS Express مشخص میکند.
- پوشهی wwwroot آن، مخصوص ارائهی فایلهای ایستا مانند wwwroot\css\bootstrap است. در ابتدای کار، این پوشه به همراه فایلهای CSS بوت استرپ است. در ادامه اگر نیاز باشد، فایلهای جاوا اسکریپتی را نیز میتوان به این قسمت اضافه کرد.
- در پوشهی Data آن، سرویس تامین اطلاعاتی اتفاقی قرار دارد؛ به نام WeatherForecastService که هدف آن، تامین اطلاعات یک جدول نمایشی است که در ادامه در آدرس https://localhost:5001/fetchdata قابل مشاهده است.
- در پوشهی Pages، تمام کامپوننتهای Razor برنامه قرار میگیرند. یکی از مهمترین صفحات آن، فایل Pages\_Host.cshtml است. کار این صفحهی ریشه، افزودن تمام فایلهای CSS و JS، به برنامهاست. بنابراین در آینده نیز از همین صفحه برای افزودن فایلهای CSS و JS استفاده خواهیم کرد. اگر به قسمت body این صفحه دقت کنیم، تگ جدید کامپوننت قابل مشاهدهاست:
<body> <component type="typeof(App)" render-mode="ServerPrerendered" />
همچنین در همینجا، تگهای دیگری نیز قابل مشاهده هستند:
<body> <component type="typeof(App)" render-mode="ServerPrerendered" /> <div id="blazor-error-ui"> <environment include="Staging,Production"> An error has occurred. This application may no longer respond until reloaded. </environment> <environment include="Development"> An unhandled exception has occurred. See browser dev tools for details. </environment> <a href="" class="reload">Reload</a> <a class="dismiss">🗙</a> </div> <script src="_framework/blazor.server.js"></script> </body>
- در پوشهی Shared، یکسری فایلهای اشتراکی قرار دارند که قرار است در کامپوننتهای واقع در پوشهی Pages مورد استفاه قرار گیرند. برای نمونه فایل Shared\MainLayout.razor، شبیه به master page برنامههای web forms است که قالب کلی سایت را مشخص میکند. داخل آن Body@ را مشاهده میکنید که به معنای نمایش صفحات دیگر، دقیقا در همین محل است. همچنین در این پوشه فایل Shared\NavMenu.razor نیز قرار دارد که ارجاعی به آن در MainLayout.razor ذکر شده و کار آن نمایش منوی آبیرنگ سمت چپ صفحهاست.
- در پوشهی ریشهی برنامه، فایل Imports.razor_ قابل مشاهدهاست. مزیت تعریف usingها در اینجا این است که از تکرار آنها در کامپوننتهای razor ای که در ادامه تهیه خواهیم کرد، جلوگیری میکند. هر using تعریف شدهی در اینجا، در تمام کامپوننتها، قابل دسترسی است؛ به آن global imports هم گفته میشود.
- در پوشهی ریشهی برنامه، فایل App.razor نیز قابل مشاهدهاست. کار آن تعریف قالب پیشفرض برنامهاست که برای مثال به Shared\MainLayout.razor اشاره میکند. همچنین کامپوننت مسیریابی نیز در اینجا ذکر شدهاست:
<Router AppAssembly="@typeof(Program).Assembly" PreferExactMatches="@true"> <Found Context="routeData"> <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" /> </Found> <NotFound> <LayoutView Layout="@typeof(MainLayout)"> <p>Sorry, there's nothing at this address.</p> </LayoutView> </NotFound> </Router>
- فایل appsettings.json نیز همانند برنامههای استاندارد ASP.NET Core در اینجا مشاهده میشود.
- فایل Program.cs آن که نقطهی آغازین برنامهاست و کار فراخوانی Startup.cs را انجام میدهد، دقیقا با یک فایل Program.cs برنامهی استاندارد ASP.NET Core یکی است.
- در فایل Startup.cs آن، همانند قبل دو متد تنظیم سرویسها و تنظیم میانافزارها قابل مشاهدهاست.
public void ConfigureServices(IServiceCollection services) { services.AddRazorPages(); services.AddServerSideBlazor(); services.AddSingleton<WeatherForecastService>(); }
قسمتهای جدید متد Configure آن، ثبت مسیریابی توکار BlazorHub است که مرتبط است با اتصال دائم SignalR برنامه و اگر مسیری پیدا نشد، به Host_ هدایت میشود:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { // ... app.UseEndpoints(endpoints => { endpoints.MapBlazorHub(); endpoints.MapFallbackToPage("/_Host"); }); }
که به همراه 13 درخواست و نزدیک به 600 KB دریافت اطلاعات از سمت سرور است.
این برنامهی نمونه، به همراه سه صفحهی نمایش Home، نمایش یک شمارشگر و نمایش اطلاعاتی از پیش آماده شدهاست. اگر صفحهی شمارشگر آنرا باز کنیم، با کلیک بر روی دکمهی آن، هرچند مقدار current count افزایش مییابد، اما شاهد post-back متداولی به سمت سرور نیستیم و این صفحه بسیار شبیه به صفحات برنامههای SPA (تک صفحهای وب) به نظر میرسد:
همانطور که عنوان شد، مدخل blazor.server.js فایل Pages\_Host.cshtml، کار به روز رسانی UI و هدایت رخدادها را به سمت سرور به صورت خودکار انجام میدهد. به همین جهت است که post-back ای را مشاهده نمیکنیم و برنامه، شبیه به یک برنامهی SPA به نظر میرسد؛ هر چند تمام رندرهای آن سمت سرور انجام میشوند و توسط SignalR به سمت کلاینت بازگشت داده خواهند شد.
برای نمونه اگر بر روی دکمهی شمارشگر کلیک کنیم، در برگهی network مرورگر، هیچ اثری از آن مشاهده نمیشود (هیچ رفت و برگشتی را مشاهده نمیکنیم). علت اینجا است که اطلاعات متناظر با این کلیک، از طریق web socket باز شدهی توسط SignalR، به سمت سرور ارسال شده و نتیجهی واکنش به این کلیکها و رندر HTML نهایی سمت سرور آن، از همین طریق به سمت کلاینت بازگشت داده میشود.
بررسی ساختار پروژهی Blazor WASM و اجرای آن
پس از اجرای دستور dotnet new blazorwasm در یک پوشهی خالی و ایجاد پروژهی ابتدایی آن:
همان صفحات پروژهی خالی Blazor Server در اینجا نیز قابل مشاهده هستند. این برنامهی نمونه، به همراه سه صفحهی نمایش Home، نمایش یک شمارشگر و نمایش اطلاعاتی از پیش آماده شدهاست. صفحات و کامپوننتهای پوشههای Pages و Shared نیز دقیقا همانند پروژهی Blazor Server قابل مشاهده هستند. مفاهیمی مانند فایلهای Imports.razor_ و App.razor نیز مانند قبل هستند.
البته در اینجا فایل Startup ای مشاهده نمیشود و تمام تنظیمات آغازین برنامه، داخل فایل Program.cs انجام خواهند شد:
namespace BlazorWasmSample { public class Program { public static async Task Main(string[] args) { var builder = WebAssemblyHostBuilder.CreateDefault(args); builder.RootComponents.Add<App>("#app"); builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) }); await builder.Build().RunAsync(); } } }
تفاوت ساختاری دیگر این پروژهی WASM، با نمونهی Blazor Server، ساختار پوشهی wwwroot آن است:
که به همراه فایل جدید نمونهی wwwroot\sample-data\weather.json است؛ بجای سرویس متناظر سمت سرور آن در برنامهی blazor server. همچنین فایل جدید wwwroot\index.html نیز قابل مشاهدهاست و محتوای تگ body آن به صورت زیر است:
<body> <div id="app">Loading...</div> <div id="blazor-error-ui"> An unhandled error has occurred. <a href="" class="reload">Reload</a> <a class="dismiss">🗙</a> </div> <script src="_framework/blazor.webassembly.js"></script> </body>
- در ابتدای بارگذاری برنامه، یک loading نمایش داده میشود که در اینجا نحوهی تعریف آن مشخص است. همچنین اگر خطایی رخ دهد نیز توسط div ای با id مساوی blazor-error-ui اطلاع رسانی میشود.
- مدخل blazor.webassembly.js در اینجا، کار دریافت وب اسمبلی و فایلهای NET runtime. را انجام میدهد؛ برخلاف برنامههای Blazor Server که توسط فایل blazor.server.js، یک ارتباط دائم SignalR را با سرور برقرار میکردند تا کدهای رندر شدهی سمت سرور را دریافت و نمایش دهند و یا اطلاعاتی را به سمت سرور ارسال کنند: برای مثال بر روی دکمهای کلیک شدهاست، اطلاعات مربوطه را در سمت سرور پردازش کن و نتیجهی نهایی رندر شده را بازگشت بده. اما در اینجا همه چیز داخل مرورگر اجرا میشود و برای این نوع اعمال، رفت و برگشتی به سمت سرور صورت نمیگیرد. به همین جهت تمام کدهای #C ما به سمت کلاینت ارسال شده و داخل مرورگر به کمک فناوری وب اسمبلی، اجرا میشوند. در اینجا از لحاظ ارسال تمام کدهای مرتبط با UI برنامهی سمت کلاینت به مرورگر کاربر، تفاوتی با فریمورکهایی مانند Angular و یا React نیست و آنها هم تمام کدهای UI برنامه را کامپایل کرده و یکجا ارسال میکنند.
در ادامه در همان پوشه، دستور dotnet run را اجرا میکنیم تا پروژه کامپایل و همچنین وب سرور آن نیز اجرا شده و برنامه در آدرس https://localhost:5001 قابل دسترسی شود.
که به همراه 205 درخواست و نزدیک به 9.6 MB دریافت اطلاعات از سمت سرور است. البته اگر همین صفحه را refresh کنیم، دیگر شاهد دریافت مجدد فایلهای DLL مربوط به NET Runtime. نخواهیم بود و اینبار از کش مرورگر خوانده میشوند:
در این برنامهی سمت کلاینت، ابتدا تمام فایلهای NET Runtime. و وب اسمبلی دریافت شده و سپس اجرای تغییرات UI، در همین سمت و بدون نیاز به اتصال دائم SignalR ای به سمت سرور، پردازش و نمایش داده میشوند. به همین جهت زمانیکه بر روی دکمهی شمارشگر آن کلیک میکنیم، اتفاقی در برگهی network مرورگر ثبت نمیشود و رفت و برگشتی به سمت سرور صورت نمیگیرد.
عدم وجود اتصال SignalR، مزیت امکان اجرای آفلاین برنامهی WASM را نیز میسر میکند. برای مثال یکبار دیگر همان برنامهی Blazor Server را به کمک دستور dotnet run اجرا کنید. سپس آنرا در مرورگر در آدرس https://localhost:5001 باز کنید. اکنون پنجرهی کنسولی که dotnet run را اجرا کرده، خاتمه دهید (قسمت اجرای سمت سرور آنرا ببندید).
بلافاصله تصویر «سعی در اتصال مجدد» فوق را مشاهده خواهیم کرد که به دلیل قطع اتصال SignalR رخ دادهاست. یعنی یک برنامهی Blazor Server، بدون این اتصال دائم، قادر به ادامهی فعالیت نیست. اما چنین محدودیتی با برنامههای Blazor WASM وجود ندارد.
البته بدیهی است اگر یک Web API سمت سرور برای ارائهی اطلاعاتی به برنامهی WASM نیاز باشد، API سمت سرور برنامه نیز باید جهت کار و نمایش اطلاعات در سمت کلاینت در دسترس باشد؛ وگرنه قسمتهای متناظر با آن، قادر به نمایش و یا ثبت اطلاعات نخواهند بود.