Introduction to ASP.NET Core part 15: starting with tag helpers
Introduction to ASP.NET Core part 14: the view start and the layout files
Introduction to ASP.NET Core part 13: the view imports file
Introduction to ASP.NET Core part 12: data annotation of view models
Introduction to ASP.NET Core part 11: inserting a new Book in a form
Introduction to ASP.NET Core part 10: the details page and more on view models
Introduction to ASP.NET Core part 9: MVC continued with routing
Introduction to ASP.NET Core part 8: MVC continued with controller actions and our first view
Introduction to ASP.NET Core part 7: starting with MVC
Introduction to ASP.NET Core part 6: environments and settings
Introduction to ASP.NET Core part 5: static files
Introduction to ASP.NET Core part 4: middleware and the component pipeline
Introduction to ASP.NET Core part 3: the configuration file
Introduction to ASP.NET Core part 2: dependencies and dependency injection
Introduction to ASP.NET Core part 1: anatomy of an empty web project
روش جاری شباهت زیادی به استفاده از Context در React دارد:
Context provides a way to pass data through the component tree without having to pass props down manually at every level
// parent component providing 'foo' var Provider = { provide: { foo: 'bar' }, // ... }
// child component injecting 'foo' var Child = { inject: ['foo'], created () { console.log(this.foo) // => "bar" } // ... }
Using an injected value as the default for a prop //دریافت میکنیم props در قسمت child را در کامپوننت foo مقدار const Child = { inject: ['foo'], props: { bar: { default () { return this.foo } } } } Using an injected value as data entry //دریافت میکنیم data در قسمت child را در کامپوننت foo مقدار const Child = { inject: ['foo'], data () { return { bar: this.foo } } }
<!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <script src="https://cdn.jsdelivr.net/npm/vue"></script> <title>Dependency injection</title> </head> <body> <div id="app"> <button @click="counter++">Increment counter</button> <h2>Parent</h2> <p>{{counter}}</p> <div> <h3>Child</h3> <child></child> </div> </div> <script> const Child = { inject: ['counter_in_child'], template: `<div>Counter Child is:{{ counter_in_child }}</div>` }; new Vue ({ el: "#app", components: { Child }, provide() { return { counter_in_child: this.counter }; }, data() { return { counter: 0 }; } }); </script> </body> </html>
<!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <script src="https://cdn.jsdelivr.net/npm/vue"></script> <title>Dependency injection</title> </head> <body> <div id="app"> <button @click="counter++">Increment counter</button> <h2>Parent</h2> <p>{{counter}}</p> <div> <h3>Child</h3> <child></child> </div> </div> <script> const Child = { inject: ['counter_in_child'], template: `<div>Counter Child is:{{ counter_in_child.counter }}</div>` }; new Vue ({ el: "#app", components: { Child }, provide() { const counter_in_child={}; Object.defineProperty(counter_in_child,'counter',{ enumerable:true, get:()=>this.counter }) return { counter_in_child }; }, data() { return { counter: 0 }; } }); </script> </body> </html>
provide
and inject
are primarily provided for advanced plugin / component library use cases. It is NOT recommended to use them in generic application code WCF Routing Service چیست؟
Routing Service به عنوان سرویس مسیریابی WCF در دات نت 4 معرفی شد. به وسیله Routing Service میتوان Endpoint Configuration مقصدهای مختلف را با هم تجمیع کرد و در نتیجه تعداد تنظیمات برای Endpoint در سمت کلاینت کاهش پیدا میکند به طوری که کلاینت فقط با یک مقصد در ارتباط است. مقصد کلاینت همان Routing Service میباشد که در این سرور درخواستهای رسیده از کلاینتها با توجه به فیلتر انجام شده به مقصد اصلی ارسال خواهند شد.
با استفاده از Routing Service معماری سیستم به صورت تغییر پیدا میکند:
اهداف:
موارد زیر اهداف و مزایای استفاده از Routing Service است:
»Service versioning
»Content-based routing scenario
»Service partitioning
»Protocol bridging
هر کدام از موارد بالا در طی پستهای جداگانه شرح داده خواهند شد.
بررسی یک مثال:
دو Contract به صورت زیر تعریف میکنیم:
[ServiceContract] public interface ICalculatorV1 { [OperationContract] int Add(int a, int b); } [ServiceContract] public interface ICalculatorV2 { [OperationContract] int Sub(int a, int b); }
public class CalculatorV1 : ICalculatorV1 { public int Add(int a, int b) { return a + b; } } public class CalculatorV2 : ICalculatorV2 { public int Sub(int a, int b) { return a - b; } }
system.serviceModel> <services> <service name="WCFRoutingSample.CalculatorV1"> <host> <baseAddresses> <add baseAddress = "http://localhost:8732/CalculatorServiceV1/" /> </baseAddresses> </host> <endpoint address ="" binding="basicHttpBinding" contract="WCFRoutingSample.ICalculatorV1"> <identity> <dns value="localhost"/> </identity> </endpoint> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> <service name="WCFRoutingSample.CalculatorV2"> <host> <baseAddresses> <add baseAddress = "http://localhost:8733/CalculatorServiceV2/" /> </baseAddresses> </host> <endpoint address ="" binding="basicHttpBinding" contract="WCFRoutingSample.ICalculatorV2"> <identity> <dns value="localhost"/> </identity> </endpoint> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> </services> <behaviors> <serviceBehaviors> <behavior> <serviceMetadata httpGetEnabled="True"/> <serviceDebug includeExceptionDetailInFaults="False" /> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel>
حال باید RoutingService را به صورت زیر هاست نماییم:
class Program { static void Main(string[] args) { var host = new ServiceHost(typeof(RoutingService)); host.Open(); Console.WriteLine("Server is running."); Console.ReadLine(); host.Close(); } }
مهمترین بخش تنظیمات مربوط به Routing Service است:
<system.serviceModel> <behaviors> <serviceBehaviors> <behavior name="routingBehv"> <routing routeOnHeadersOnly="false" filterTableName="filters"/> <serviceDebug includeExceptionDetailInFaults="true"/> <serviceMetadata httpGetEnabled="true"/> </behavior> </serviceBehaviors> </behaviors> <routing> <filters> <filter name="CalV1ServiceFilter" filterType="EndpointName" filterData="Calv1Service"/> <filter name="CalV2ServiceFilter" filterType="EndpointName" filterData="Calv2Service"/> </filters> <filterTables> <filterTable name="filters"> <add filterName="CalV1ServiceFilter" endpointName="Calv1Service" /> <add filterName="CalV2ServiceFilter" endpointName="Calv2Service"/> </filterTable> </filterTables> </routing> <services> <!-- Routing service with endpoint definition --> <service name="System.ServiceModel.Routing.RoutingService" behaviorConfiguration="routingBehv"> <endpoint address="/Calv1" binding="basicHttpBinding" contract="System.ServiceModel.Routing.IRequestReplyRouter" name="Calv1Service"/> <endpoint address="/Calv2" binding="basicHttpBinding" contract="System.ServiceModel.Routing.IRequestReplyRouter" name="Calv2Service"/> <host> <baseAddresses> <add baseAddress="http://localhost:9000/CalculatorService"/> </baseAddresses> </host> </service> </services> <client> <endpoint address="http://localhost:8732/CalculatorServiceV1" binding="basicHttpBinding" contract="*" name="Calv1Service"/> <endpoint address="http://localhost:8733/CalculatorServiceV2" binding="basicHttpBinding" contract="*" name="Calv2Service"/> </client> </system.serviceModel>
الف) تزریق وابستگیها در سازنده کلاس
ب) تزریق وابستگیها در خواص عمومی کلاسها یا Setters injection
حالت الف متداولترین است و بیشتر زمانی کاربرد دارد که کار وهله سازی یک کلاس را میتوان راسا انجام داد. اما در فرمها یا یوزرکنترلهای ASP.NET Web forms به صورت پیش فرض کار وهله سازی فرمها و یوزرکنترلها توسط موتور ASP.NET انجام میشود و در این حالت اگر بخواهیم از تزریق وابستگیها استفاده کنیم، مدام به همان روش معروف Service locator و استفاده از container.Resolve در تمام قسمتهای برنامه میرسیم که آنچنان روش مطلوبی نیست.
اما ... در ASP.NET Web forms میتوان وهله سازی فرمها را نیز تحت کنترل قرار داد، که برای آن دو روش زیر وجود دارند:
الف) یک کلاس مشتق شده را از کلاس پایه PageHandlerFactory تهیه کنیم. این کلاس را پیاده سازی کرده و نهایتا بجای وهله ساز پیش فرض فرمهای موتور داخلی ASP.NET، در فایل وب کانفیگ برنامه استفاده کنیم. یک نمونه از پیاده سازی آنرا در اینجا میتوانید مشاهده کنید.
مشکلی که این روش دارد سازگاری آن با حالت Full trust است. یعنی برنامه شما در یک هاست Medium trust (اغلب هاستهای خوب) اجرا نخواهد شد.
ب) روش دوم، استفاده از یک Http Module است برای اعمال Setter injectionها، به صورت خودکار. اکنون که حالت الف را همه جا نمیتوان بکار برد یا به عبارتی نمیتوان وهله سازی فرمها را راسا در دست گرفت، حداقل میتوان خواص عمومی اشیاء صفحه تولید شده را مقدار دهی کرد که در ادامه، این روش را بررسی میکنیم.
تهیه ماژول انجام Setters injection به صورت خودکار در برنامههای ASP.NET Web forms به کمک StructureMap
پیشنیاز این بحث، مطلب «استفاده از StructureMap به عنوان یک IoC Container» میباشد که پیشتر مطالعه کردید (در حد نحوه نصب StructureMap و آشنایی با تنظیمات اولیه آن)
using System.Collections; using System.Web; using System.Web.UI; using StructureMap; namespace DI05.Core { /// <summary> /// تسهیل در کار تزریق خودکار وابستگیها در سطح فرمها و یوزرکنترلها /// </summary> public class StructureMapModule : IHttpModule { public void Dispose() { } public void Init(HttpApplication app) { app.PreRequestHandlerExecute += (sender, e) => { var page = HttpContext.Current.Handler as Page; // The Page handler if (page == null) return; WireUpThePage(page); WireUpAllUserControls(page); }; } private static void WireUpAllUserControls(Page page) { // در اینجا هم کار سیم کشی یوزر کنترلها انجام میشود page.InitComplete += (initSender, evt) => { var thisPage = (Page)initSender; foreach (Control ctrl in getControlTree(thisPage)) { // فقط یوزر کنترلها بررسی شدند // اگر نیاز است سایر کنترلهای قرار گرفته روی فرم هم بررسی شوند شرط را حذف کنید if (ctrl is UserControl) { ObjectFactory.BuildUp(ctrl); } } }; } private static void WireUpThePage(Page page) { ObjectFactory.BuildUp(page); // برقراری خودکار سیم کشیها در سطح صفحات } private static IEnumerable getControlTree(Control root) { foreach (Control child in root.Controls) { yield return child; foreach (Control ctrl in getControlTree(child)) { yield return ctrl; } } } } }
پس از تهیه ماژول فوق، باید آنرا در فایل وب کانفیگ برنامه معرفی کرد:
<?xml version="1.0"?> <configuration> <system.web> <compilation debug="true" targetFramework="4.0" /> <httpModules> <add name="StructureMapModule" type="DI05.Core.StructureMapModule"/> </httpModules> </system.web> <system.webServer> <modules runAllManagedModulesForAllRequests="true"> <add name="StructureMapModule" type="DI05.Core.StructureMapModule"/> </modules> <validation validateIntegratedModeConfiguration="false" /> </system.webServer> </configuration>
مثالی از نحوه استفاده از StructureMapModule تهیه شده
فرض کنید لایه سرویس برنامه دارای اینترفیسها و کلاسهای زیر است:
namespace DI05.Services { public interface IUsersService { string GetUserEmail(int id); } } namespace DI05.Services { public class UsersService: IUsersService { public string GetUserEmail(int id) { //فقط جهت بررسی تزریق وابستگیها return "test@test.com"; } } }
using System; using StructureMap; using DI05.Services; namespace DI05 { public class Global : System.Web.HttpApplication { private static void initStructureMap() { ObjectFactory.Initialize(x => { x.For<IUsersService>().Use<UsersService>(); x.SetAllProperties(y => { y.OfType<IUsersService>(); }); }); } protected void Application_Start(object sender, EventArgs e) { initStructureMap(); } void Application_EndRequest(object sender, EventArgs e) { ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects(); } } }
مرحله آخر هم استفاده از سرویسهای برنامه به شکل زیر است:
using System; using DI05.Services; namespace DI05 { public partial class Default : System.Web.UI.Page { public IUsersService UsersService { set; get; } protected void Page_Load(object sender, EventArgs e) { lblEmail1.Text = string.Format("From Default Page: {0}", UsersService.GetUserEmail(1)); } } }
دریافت مثال کامل قسمت جاری
DI05.zip
یک نکتهی تکمیلی
برای ارتقاء نکات مطلب جاری به نگارش سوم StructureMap نیاز است موارد ذیل را لحاظ کنید:
الف) نصب بستهی وب آن
PM> Install-Package structuremap.web
ج) x.SetAllProperties را به x.Policies.SetAllProperties ویرایش کنید.
افزودن کامپوننت دسترسی به منابع محافظت شده، به ماژول Dashboard
در اینجا قصد داریم صفحهای را به برنامه اضافه کنیم تا در آن بتوان اطلاعات کنترلرهای محافظت شدهی سمت سرور، مانند MyProtectedAdminApiController (تنها قابل دسترسی توسط کاربرانی دارای نقش Admin) و MyProtectedApiController (قابل دسترسی برای عموم کاربران وارد شدهی به سیستم) را دریافت و نمایش دهیم. به همین جهت کامپوننت جدیدی را به ماژول Dashboard اضافه میکنیم:
>ng g c Dashboard/CallProtectedApi
import { CallProtectedApiComponent } from "./call-protected-api/call-protected-api.component"; const routes: Routes = [ { path: "callProtectedApi", component: CallProtectedApiComponent, data: { permission: { permittedRoles: ["Admin", "User"], deniedRoles: null } as AuthGuardPermission }, canActivate: [AuthGuard] } ];
لینکی را به این صفحه نیز در فایل header.component.html به صورت ذیل اضافه خواهیم کرد تا فقط توسط کاربران وارد شدهی به سیستم (isLoggedIn) قابل مشاهده باشد:
<li *ngIf="isLoggedIn" routerLinkActive="active"> <a [routerLink]="['/callProtectedApi']">Call Protected Api</a> </li>
نمایش و یا مخفی کردن قسمتهای مختلف صفحه بر اساس نقشهای کاربر وارد شدهی به سیستم
در ادامه میخواهیم دو دکمه را بر روی صفحه قرار دهیم تا اطلاعات کنترلرهای محافظت شدهی سمت سرور را بازگشت دهند. دکمهی اول قرار است تنها برای کاربر Admin قابل مشاهده باشد و دکمهی دوم توسط کاربری با نقشهای Admin و یا User.
به همین جهت call-protected-api.component.ts را به صورت ذیل تغییر میدهیم:
import { Component, OnInit } from "@angular/core"; import { AuthService } from "../../core/services/auth.service"; @Component({ selector: "app-call-protected-api", templateUrl: "./call-protected-api.component.html", styleUrls: ["./call-protected-api.component.css"] }) export class CallProtectedApiComponent implements OnInit { isAdmin = false; isUser = false; result: any; constructor(private authService: AuthService) { } ngOnInit() { this.isAdmin = this.authService.isAuthUserInRole("Admin"); this.isUser = this.authService.isAuthUserInRole("User"); } callMyProtectedAdminApiController() { } callMyProtectedApiController() { } }
<button *ngIf="isAdmin" (click)="callMyProtectedAdminApiController()"> Call Protected Admin API [Authorize(Roles = "Admin")] </button> <button *ngIf="isAdmin || isUser" (click)="callMyProtectedApiController()"> Call Protected API ([Authorize]) </button> <div *ngIf="result"> <pre>{{result | json}}</pre> </div>
دریافت اطلاعات از کنترلرهای محافظت شدهی سمت سرور
برای دریافت اطلاعات از کنترلرهای محافظت شده، باید در قسمتی که HttpClient درخواست خود را به سرور ارسال میکند، هدر مخصوص Authorization را که شامل توکن دسترسی است، به سمت سرور ارسال کرد. این هدر ویژه را به صورت ذیل میتوان در AuthService تولید نمود:
getBearerAuthHeader(): HttpHeaders { return new HttpHeaders({ "Content-Type": "application/json", "Authorization": `Bearer ${this.getRawAuthToken(AuthTokenType.AccessToken)}` }); }
روش دوم انجام اینکار که مرسومتر است، اضافه کردن خودکار این هدر به تمام درخواستهای ارسالی به سمت سرور است. برای اینکار باید یک HttpInterceptor را تهیه کرد. به همین منظور فایل جدید app\core\services\auth.interceptor.ts را به برنامه اضافه کرده و به صورت ذیل تکمیل میکنیم:
import { Injectable } from "@angular/core"; import { HttpEvent, HttpInterceptor, HttpHandler, HttpRequest } from "@angular/common/http"; import { Observable } from "rxjs/Observable"; import { AuthService, AuthTokenType } from "./auth.service"; @Injectable() export class AuthInterceptor implements HttpInterceptor { constructor(private authService: AuthService) { } intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { const accessToken = this.authService.getRawAuthToken(AuthTokenType.AccessToken); if (accessToken) { request = request.clone({ headers: request.headers.set("Authorization", `Bearer ${accessToken}`) }); } return next.handle(request); } }
به این ترتیب دیگری نیازی نیست تا به ازای هر درخواست و هر قسمتی از برنامه، این هدر را به صورت دستی تنظیم کرد و اضافه شدن آن پس از تنظیم ذیل، به صورت خودکار انجام میشود:
import { HTTP_INTERCEPTORS } from "@angular/common/http"; import { AuthInterceptor } from "./services/auth.interceptor"; @NgModule({ providers: [ { provide: HTTP_INTERCEPTORS, useClass: AuthInterceptor, multi: true } ] }) export class CoreModule {}
در این حالت اگر برنامه را اجرا کنید، خطای ذیل را در کنسول توسعهدهندههای مرورگر مشاهده خواهید کرد:
compiler.js:19514 Uncaught Error: Provider parse errors: Cannot instantiate cyclic dependency! InjectionToken_HTTP_INTERCEPTORS ("[ERROR ->]"): in NgModule AppModule in ./AppModule@-1:-1
import { Injector } from "@angular/core"; constructor(private injector: Injector) { } intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { const authService = this.injector.get(AuthService);
@Injectable() export class AuthInterceptor implements HttpInterceptor { constructor(private injector: Injector) { } intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { const authService = this.injector.get(AuthService); const accessToken = authService.getRawAuthToken(AuthTokenType.AccessToken); if (accessToken) { request = request.clone({ headers: request.headers.set("Authorization", `Bearer ${accessToken}`) }); } return next.handle(request); } }
تکمیل متدهای دریافت اطلاعات از کنترلرهای محافظت شدهی سمت سرور
اکنون پس از افزودن AuthInterceptor، میتوان متدهای CallProtectedApiComponent را به صورت ذیل تکمیل کرد. ابتدا سرویسهای Auth ،HttpClient و همچنین تنظیمات آغازین برنامه را به سازندهی CallProtectedApiComponent تزریق میکنیم:
constructor( private authService: AuthService, private httpClient: HttpClient, @Inject(APP_CONFIG) private appConfig: IAppConfig, ) { }
callMyProtectedAdminApiController() { this.httpClient .get(`${this.appConfig.apiEndpoint}/MyProtectedAdminApi`) .map(response => response || {}) .catch((error: HttpErrorResponse) => Observable.throw(error)) .subscribe(result => { this.result = result; }); } callMyProtectedApiController() { this.httpClient .get(`${this.appConfig.apiEndpoint}/MyProtectedApi`) .map(response => response || {}) .catch((error: HttpErrorResponse) => Observable.throw(error)) .subscribe(result => { this.result = result; }); }
در این حالت اگر برنامه را اجرا کنید، افزوده شدن خودکار هدر مخصوص Authorization:Bearer را در درخواست ارسالی به سمت سرور، مشاهده خواهید کرد:
مدیریت خودکار خطاهای عدم دسترسی ارسال شدهی از سمت سرور
ممکن است کاربری درخواستی را به منبع محافظت شدهای ارسال کند که به آن دسترسی ندارد. در AuthInterceptor تعریف شده میتوان به وضعیت این خطا، دسترسی یافت و سپس کاربر را به صفحهی accessDenied که در قسمت قبل ایجاد کردیم، به صورت خودکار هدایت کرد:
return next.handle(request) .catch((error: any, caught: Observable<HttpEvent<any>>) => { if (error.status === 401 || error.status === 403) { this.router.navigate(["/accessDenied"]); } return Observable.throw(error); });
@Injectable() export class AuthInterceptor implements HttpInterceptor { constructor( private injector: Injector, private router: Router) { } intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { const authService = this.injector.get(AuthService); const accessToken = authService.getRawAuthToken(AuthTokenType.AccessToken); if (accessToken) { request = request.clone({ headers: request.headers.set("Authorization", `Bearer ${accessToken}`) }); return next.handle(request) .catch((error: any, caught: Observable<HttpEvent<any>>) => { if (error.status === 401 || error.status === 403) { this.router.navigate(["/accessDenied"]); } return Observable.throw(error); }); } else { // login page return next.handle(request); } } }
using ASPNETCore2JwtAuthentication.Services; using Microsoft.AspNetCore.Authorization; using Microsoft.AspNetCore.Cors; using Microsoft.AspNetCore.Mvc; namespace ASPNETCore2JwtAuthentication.WebApp.Controllers { [Route("api/[controller]")] [EnableCors("CorsPolicy")] [Authorize(Policy = CustomRoles.Editor)] public class MyProtectedEditorsApiController : Controller { public IActionResult Get() { return Ok(new { Id = 1, Title = "Hello from My Protected Editors Controller! [Authorize(Policy = CustomRoles.Editor)]", Username = this.User.Identity.Name }); } } }
callMyProtectedEditorsApiController() { this.httpClient .get(`${this.appConfig.apiEndpoint}/MyProtectedEditorsApi`) .map(response => response || {}) .catch((error: HttpErrorResponse) => Observable.throw(error)) .subscribe(result => { this.result = result; }); }
نکتهی مهم: نیاز به دائمی کردن کلیدهای رمزنگاری سمت سرور
اگر برنامهی سمت سرور ما که توکنها را اعتبارسنجی میکند، ریاستارت شود، چون قسمتی از کلیدهای رمزگشایی اطلاعات آن با اینکار مجددا تولید خواهند شد، حتی با فرض لاگین بودن شخص در سمت کلاینت، توکنهای فعلی او برگشت خواهند خورد و از مرحلهی تعیین اعتبار رد نمیشوند. در این حالت کاربر خطای 401 را دریافت میکند. بنابراین پیاده سازی مطلب «غیرمعتبر شدن کوکیهای برنامههای ASP.NET Core هاست شدهی در IIS پس از ریاستارت آن» را فراموش نکنید.
کدهای کامل این سری را از اینجا میتوانید دریافت کنید.
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس از طریق خط فرمان به ریشهی پروژهی ASPNETCore2JwtAuthentication.AngularClient وارد شده و دستور npm install را صادر کنید تا وابستگیهای آن دریافت و نصب شوند. در آخر با اجرای دستور ng serve -o، برنامه ساخته شده و در مرورگر پیش فرض سیستم نمایش داده خواهد شد (و یا همان اجرای فایل ng-serve.bat). همچنین باید به پوشهی ASPNETCore2JwtAuthentication.WebApp نیز مراجعه کرده و فایل dotnet_run.bat را اجرا کنید، تا توکن سرور برنامه نیز فعال شود.
منابع اصلی Ember.js
پیش از شروع به بحث نیاز است با تعدادی از سایتهای اصلی مرتبط با Ember.js آشنا شد:
سایت اصلی: http://emberjs.com
مخزن کدهای آن: https://github.com/emberjs
انجمن اختصاصی پرسش و پاسخ: http://discuss.emberjs.com
موتور قالبهای آن: http://handlebarsjs.com
لیست منابع مطالعاتی مرتبط مانند ویدیوهای آموزشی و لیست مقالات موجود: http://emberwatch.com
و بستهی نیوگت آن: https://www.nuget.org/packages/EmberJS
مفاهیم پایهای Ember.js
شیء Application
App = Ember.Application.create();
مسیر یابی
با مرور قسمتهای مختلف برنامه توسط کاربر، نیاز است حالات برنامه را مدیریت کرد؛ اینجا است که کار قسمت مسیریابی شروع میشود. مسیریابی، منابع مورد نیاز جهت آدرسهای مشخصی را تامین میکند.
App.Router.map(function() { this.resource('accounts'); // takes us to /accounts this.resource('gallery'); // takes us to /gallery });
به این ترتیب مسیرهای accounts/ و gallery/ قابل پردازش خواهند شد.
این مسیرها، تو در تو نیز میتوانند باشند. برای مثال:
App.Router.map(function() { this.resource('news', function() { this.resource('images', function () { // takes us to /news/images this.route('add');// takes us to /news/images/add }); }); });
مدلها
مدلها همان اشیایی هستند که برنامه مورد استفاده قرار میدهد و میتوانند یک آرایهی ساده و یا اشیاء JSON دریافتی از وب سرور باشند.
حداقل به دو روش میتوان مدلها را تعریف کرد:
الف) با استفاده از افزونهی Ember Data
ب) با کمک شیء Ember.Object
App.SiteLink = Ember.Object.extend({}); App.SiteLink.reopenClass({ findAll: function() { var links = []; //… $.getJSON … return links; } });
در ادامه متد دلخواهی را ایجاد کرده و برای مثال آرایهای از اشیاء دلخواه جاوا اسکریپتی را بازگشت خواهیم داد.
پس از تعریف مدل، نیاز است آنرا به سیستم مسیریابی معرفی کرد:
App.GalleryRoute = Ember.Route.extend({ model: function() { return App.SiteLink.findAll(); } });
کنترلرها
کنترلرها جهت ارائهی اطلاعات مدلها به View و قالب برنامه تعریف میشوند. در اینجا همیشه باید بخاطر داشت که model تامین کنندهی اطلاعات است. کنترلر جهت در معرض دید قرار دادن این اطلاعات، به View برنامه کاربرد دارد و مدلها هیچ اطلاعی از وجود کنترلرها ندارند.
کنترلرها علاوه بر اطلاعات model، میتوانند حاوی یک سری خواص و اشیاء صرفا نمایشی که قرار نیست در بانک اطلاعاتی ذخیره شوند نیز باشند.
در Ember.js قالبها (templates) اطلاعات خود را از کنترلر دریافت میکنند. کنترلرها اطلاعات مدل را به همراه سایر خواص نمایشی مورد نیاز در اختیار View و قالبهای برنامه قرار میدهند.
برای تعریف یک کنترلر میتوان درون شیء مسیریابی، با تعریف متد setupController شروع کرد:
App.GalleryRoute = Ember.Route.extend({ setupController: function(controller) { controller.set('content', ['red', 'yellow', 'blue']); } });
روش دوم تعریف کنترلرها با ایجاد یک زیر کلاس از شیء Ember.Controller انجام میشود:
App.GalleryController = Ember.Controller.extend({ search: '', content: ['red', 'yellow', 'blue'], query: function() { var data = this.get('search'); this.transitionToRoute('search', { query: data }); } });
قالبها یا templates
قالبها قسمتهای اصلی رابط کاربری را تشکیل خواهند داد. در اینجا از کتابخانهای به نام handlebars برای تهیه قالبهای سمت کاربر کمک گرفته میشود.
<script type="text/x-handlebars" data-template-name="sayhello"> Hello, <strong>{{firstName}} {{lastName}}</strong>! </script>
<script type="text/x-handlebars" data-template-name="sayhello"> Hello, <strong>{{firstName}} {{lastName}}</strong>! {{#if person}} Welcome back, <strong>{{person.firstName}} {{person.lastName}}</strong>! {{/if}} <ul> {{#each friend in friends}} <li> {{friend.name}} </li> {{/each}} </ul> <img {{bindAttr src="link.url" }} /> {{#linkTo ''about}}About{{/linkTo}} </script>
بهترین مرجع آشنایی با ریز جزئیات کتابخانهی handlebars، مراجعه به سایت اصلی آن است.
قواعد پیش فرض نامگذاری در Ember.js
اگر به مثالهای فوق دقت کرده باشید، خواصی مانند GalleryController و یا GalleryRoute به شیء App اضافه شدهاند. این نوع نامگذاریها در ember.js بر اساس روش convention over configuration کار میکنند. برای نمونه اگر مسیریابی خاصی را به نحو ذیل تعریف کردید:
this.resource('employees');
کنترلر آن App.EmployeesController
مدل آن App.Employee
View آن App.EmployeesView
و قالب آن employees
بهتر است تعریف شوند. به عبارتی اگر اینگونه تعریف شوند، به صورت خودکار توسط Ember.js یافت شده و هر کدام با مسئولیتهای خاص مرتبط با آنها پردازش میشوند و همچنین ارتباطات بین آنها به صورت خودکار برقرار خواهد شد. به این ترتیب برنامه نظم بهتری خواهد یافت. با یک نگاه میتوان قسمتهای مختلف را تشخیص داد و همچنین کدنویسی پردازش و اتصال قسمتهای مختلف برنامه نیز به شدت کاهش مییابد.
تهیهی اولین برنامهی Ember.js
تا اینجا نگاهی مقدماتی داشتیم به اجزای تشکیل دهندهی هستهی Ember.js. در ادامه مثال سادهای را جهت نمایش ساختار ابتدایی یک برنامهی Ember.js، بررسی خواهیم کرد.
بستهی Ember.js را همانطور که در قسمت منابع اصلی آن در ابتدای بحث عنوان شد، میتوانید از سایت و یا مخزن کد آن دریافت کنید و یا اگر از VS.NET استفاده میکنید، تنها کافی است دستور ذیل را صادر نمائید:
PM> Install-Package EmberJS
در این حالت ترتیب تعریف اسکریپتهای مورد نیاز صفحه به صورت ذیل خواهند بود:
<script src="Scripts/jquery-2.1.1.js" type="text/javascript"></script> <script src="Scripts/handlebars.js" type="text/javascript"></script> <script src="Scripts/ember.js" type="text/javascript"></script> <script src="Scripts/app.js" type="text/javascript"></script>
App = Ember.Application.create(); App.IndexRoute = Ember.Route.extend({ setupController:function(controller) { controller.set('content', ['red', 'yellow', 'blue']); } });
App.Router.map(function() { this.resource('application'); this.resource('index'); });
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> <script src="Scripts/jquery-2.1.1.js" type="text/javascript"></script> <script src="Scripts/handlebars.js" type="text/javascript"></script> <script src="Scripts/ember.js" type="text/javascript"></script> <script src="Scripts/app.js" type="text/javascript"></script> </head> <body> <script type="text/x-handlebars" data-template-name="index"> Hello, <strong>Welcome to Ember.js</strong>! <ul> {{#each item in content}} <li> {{item}} </li> {{/each}} </ul> </script> </body> </html>
مقدار data-template-name در اینجا مهم است. اگر آنرا به هر نام دیگری بجز index تنظیم کنید، منبع دریافت اطلاعات آن مشخص نخواهد بود. نام index در اینجا به معنای اتصال این قالب به اطلاعات ارائه شده توسط کنترلر index است.
تا همینجا اگر برنامه را اجرا کنید، به خوبی کار خواهد کرد. نکتهی دیگری که در مورد قالبهای Ember.js قابل توجه هستند، قالب پیش فرض application است. با تعریف Ember.Application.create یک چنین قالبی نیز به ابتدای هر صفحه به صورت خودکار اضافه خواهد شد:
<body> <script type="text/x-handlebars" data-template-name="application"> <h1>Header</h1> {{outlet}} </script>
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید:
EmberJS01.zip
پیشنیازهای سمت سرور
- ابتدا یک پروژهی خالی ASP.NET را ایجاد کنید. نوع آن مهم نیست که Web Forms باشد یا MVC.
- سپس قصد داریم مدل کاربران سیستم را توسط یک ASP.NET Web API Controller در اختیار Ember.js قرار دهیم. مباحث پایهای Web API نیز در وب فرمها و MVC یکی است.
مدل سمت سرور برنامه چنین شکلی را دارد:
namespace EmberJS02.Models { public class User { public int Id { set; get; } public string UserName { set; get; } public string Email { set; get; } } }
using System.Collections.Generic; using System.Web.Http; using EmberJS02.Models; namespace EmberJS02.Controllers { public class UsersController : ApiController { // GET api/<controller> public IEnumerable<User> Get() { return UsersDataSource.UsersList; } } }
همچنین فرض بر این است که مسیریابی سمت سرور ذیل را نیز به فایل global.asax.cs، جهت فعال سازی دسترسی به متدهای کنترلر UsersController تعریف کردهاید:
using System; using System.Web.Http; using System.Web.Routing; namespace EmberJS02 { public class Global : System.Web.HttpApplication { protected void Application_Start(object sender, EventArgs e) { RouteTable.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } } }
پیشنیازهای سمت کاربر
پیشنیازهای سمت کاربر این قسمت با قسمت «تهیهی اولین برنامهی Ember.js» دقیقا یکی است.
ابتدا فایلهای مورد نیاز Ember.js به برنامه اضافه شدهاند:
PM> Install-Package EmberJS
App = Ember.Application.create(); App.IndexRoute = Ember.Route.extend({ setupController:function(controller) { controller.set('content', ['red', 'yellow', 'blue']); } });
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> <script src="Scripts/jquery-2.1.1.js" type="text/javascript"></script> <script src="Scripts/handlebars.js" type="text/javascript"></script> <script src="Scripts/ember.js" type="text/javascript"></script> <script src="Scripts/app.js" type="text/javascript"></script> </head> <body> <script type="text/x-handlebars" data-template-name="application"> <h1>Header</h1> {{outlet}} </script> <script type="text/x-handlebars" data-template-name="index"> Hello, <strong>Welcome to Ember.js</strong>! <ul> {{#each item in content}} <li> {{item}} </li> {{/each}} </ul> </script> </body> </html>
در ادامه قصد داریم به هدر صفحه، دو لینک Home و About را اضافه کنیم؛ به نحوی که لینک Home به مسیریابی index و لینک About به مسیریابی about که صفحهی جدید «دربارهی برنامه» را نمایش میدهد، اشاره کنند.
تعریف صفحهی جدید About
برنامههای Ember.js، برنامههای تک صفحهای وب هستند و صفحات جدید در آنها به صورت یک template جدید تعریف میشوند که نهایتا متناظر با یک مسیریابی مشخص خواهند بود.
به همین جهت ابتدا در فایل app.js مسیریابی about را اضافه خواهیم کرد:
App.Router.map(function() { this.resource('about'); });
بنابراین به صفحهی index.html برنامه مراجعه کرده و صفحهی about را توسط یک قالب جدید تعریف میکنیم:
<script type="text/x-handlebars" data-template-name="about"> <h2>Our about page</h2> </script>
در این حالت اگر برنامه را در حالت معمولی اجرا کنید، خروجی خاصی را مشاهده نخواهید کرد. بنابراین نیاز است تا لینکی را جهت اشاره به این مسیر جدید به صفحه اضافه کنیم:
<script type="text/x-handlebars" data-template-name="application"> <h1>Ember Demo App</h1> <ul class="nav"> <li>{{#linkTo 'index'}}Home{{/linkTo}}</li> <li>{{#linkTo 'about'}}About{{/linkTo}}</li> </ul> {{outlet}} </script>
در اینجا با استفاده از امکان یا directive ویژهای به نام linkTo، لینکهایی به مسیریابیهای index و about اضافه شدهاند. به این ترتیب اگر کاربری برای مثال بر روی لینک About کلیک کند، کتابخانهی Ember.js او را به صورت خودکار به مسیریابی about و سپس نمایش قالب مرتبط با آن (قالب about ایی که پیشتر تعریف کردیم) هدایت خواهد کرد؛ مانند تصویر ذیل:
همانطور که در آدرس صفحه نیز مشخص است، هرچند صفحهی about نمایش داده شدهاست، اما هنوز نیز در همان صفحهی اصلی برنامه قرار داریم. به علاوه در این قسمت جدید، همچنان منوی بالای صفحه نمایان است؛ از این جهت که تعاریف آن به قالب application اضافه شدهاند.
دریافت و نمایش اطلاعات از سرور
اکنون که با نحوهی تعریف یک صفحهی جدید و برپایی سیم کشیهای مرتبط با آن آشنا شدیم، میخواهیم صفحهی دیگری را به نام Users به برنامه اضافه کنیم و در آن لیست کاربران ارائه شده توسط کنترلر Web API سمت سرور ابتدای بحث را نمایش دهیم.
بنابراین ابتدا مسیریابی جدید users را به صفحه اضافه میکنیم تا لیست کاربران، در آدرس users/ قابل دسترسی شود:
App.Router.map(function() { this.resource('about'); this.resource('users'); });
App.UsersLink = Ember.Object.extend({}); App.UsersLink.reopenClass({ findAll: function () { var users = []; $.getJSON('/api/users').then(function(response) { response.forEach(function(item) { users.pushObject(App.UsersLink.create(item)); }); }); return users; } });
پس از اینکه نحوهی دریافت اطلاعات از سرور مشخص شد، باید اطلاعات این مدل را در اختیار مسیریابی Users قرار داد:
App.UsersRoute = Ember.Route.extend({ model: function() { return App.UsersLink.findAll(); } }); App.UsersController = Ember.ObjectController.extend({ customHeader : 'Our Users List' });
همچنین در کنترلری که تعریف شده، صرفا یک خاصیت سفارشی و دلخواه جدید، به نام customHeader برای نمایش در ابتدای صفحه تعریف و مقدار دهی گردیدهاست.
اکنون قالبی که قرار است اطلاعات مدل را نمایش دهد، چنین شکلی را خواهد داشت:
<script type="text/x-handlebars" data-template-name="users"> <h2>{{customHeader}}</h2> <ul> {{#each item in model}} <li> {{item.Id}}-{{item.UserName}} ({{item.Email}}) </li> {{/each}} </ul> </script>
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید:
EmberJS02.zip
آیا به یادگیری یا ادامهی استفاده از AngularJS خواهید پرداخت؟
در نگاه اول شاید برای توسعه دهندگان مبتدی یک سری مباحث گیج کننده باشن و خیلی از قابلیتها هم جادویی و جذاب. اما حقیقت امر این است که code base این فریم ورک مشکلات شگفت آوری داره. چند ساعت وقت گذاشتن روی اینترنت کافی هست تا از تمام جنبهها فریم ورکهای مطرح رو بررسی کرد و متوجه شد که Angular چقدر مشکلات اساسی داره. بصورت تیتر وار چند مورد رو لیست میکنم:
- Dynamic Scoping, and scope inheritance
- Two-way data binding with $watchers
- The $digest cycle
- No DOM manipulation capabilities
- Finite Routing, unless you use a 3rd party like ui-router
- app logic and structure expressed in HTML
- No server-side rendering (mostly for speed boost and SEO)
- string-based Dependency Injection
- Ill-Conceived architecture (obsolete constructor functions etc)
- Debugging issues
- Re-defining well established terminology
- Syntactic Sugar
- Execution Contexts
- Unnecessary Complications
- Incompatible with 3rd party libraries, like jQuery etc.
- Sparse documentation with literally no real-world examples
و مواردی از این دست. شاید برای پروژههای کوچک این فریم ورک مناسب باشه اما قطعا برای پروژههای بزرگی که قرار است برای مدتی طولانی توسعه داده بشن و نگهداری بشن اصلا انتخاب درستی نیست. حتی اگر پروژههای بزرگی هم با موفقیت توسط این فریم اجرا شده باشه باز هم ماهیت مساله تغییر نمیکنه.
در حال حاظر بین فریم ورکهای دیگه بهترین انتخاب Ember هست که بسیاری از مشکلات ذکر شده رو نداره و ساختار و معماری قوی و خوبی هم داره. Backbone و Durandal هم فریم ورکهای قوی ای هستند ولی تفاوتهای نسبتا زیادی با Ember دارن.
حائز اهمیت این که، اپلیکیشنهای SPA جوان هستند و فعلا همه جای دنیا در حال آزمایش و بررسی این هستند که چطور میشه چنین پروژه هایی رو اجرا کرد و کدام راه بهترین راه هست، بنابراین تا به استانداردهای ثابتی برسیم راه طولانی ای در پیش داریم. از طرفی بزودی استاندارد جدید جاوا اسکریپت (ECMA6) منتشر میشه، که با انتشارش فریم ورک هایی مثل Ember و Angular رو کاملا به هم خواهد ریخت. مثلا در نسخه جدید آبجکتهای Observable خواهیم داشت. بنابراین متدهای Angular و Ember برای تشخیص تغییرات به کلی بلا استفاده خواهند بود و بازنویسیهای اساسی لازم میشود.
سری بررسی مقدمات Blazor
Blazor Fundamentals Tutorial
Blazor server-side vs client-side (WebAssembly) | What should you choose?
What are Razor Components? | Blazor Tutorial 1
Dependency Injection | Blazor Tutorial 2
What are Blazor Layouts? | Blazor Tutorial 3
Routing and Navigation | Blazor Tutorial 4
JS Interop: Calling JavaScript from C# | Blazor Tutorial 5
JS Interop: Calling C# methods from JavaScript | Blazor Tutorial 6
Creating Forms with Validation | Blazor Tutorial 7
How to add Authentication in Server-side Blazor | Blazor Tutorial 8
Authorization in Server-Side Blazor | Blazor Tutorial 9
How to use HTML5 Web Storage in Blazor | Blazor Tutorial 10
Managing Blazor state using Redux | Blazor Tutorial 11
Creating a desktop application using Blazor and Electron | Blazor Tutorial 12
Deploying Server-Side Blazor in Azure with SignalR service | Blazor Tutorial 13
Building cross platform mobile apps with Blazor (Experimental)