نظرات مطالب
ماژول Http در Angular، برای برقراری ارتباط بین کلاینت و سمت سرور، مورد استفاده قرار میگیرد. معمولا هنگام ساخت درخواستهای Http، یکسری کدهای تکراری برای تنظیم هدر (برای اعتبارسنجی و همچنین تنظیمات دیگر) نوشته میشوند که در هر درخواست یکسان هستند. همچنین بعد از آمدن جواب (Response) از سمت سرور نیز یکسری کدهای تکراری جهت برسی کد response و یا تغییر فرمت اطلاعات رسیده، به ساختار مورد توافق نوشته خواهند شد.
برای مثال در صورتیکه در برنامه خود از اعتبار سنجی مبتنی بر توکن (Token Base Authentication) استفاده میکنید، قبل از ارسال هر درخواست (request)، کدهایی مشابه کد زیر باید نوشته شوند:
همچنین فرض کنید بعد از رسیدن جواب هر درخواست، میخواهید response code را چک کنید و خطاهای احتمالی را مدیریت کنید. مثلا درصورت دریافت کد 401، کاربر را به صفحه «ورود» و با دریافت کد 404 آنرا را به صفحه «یافت نشد» هدایت کنید و یا با دریافت کد 403 یا 500 پیغام مناسبی را نمایش دهید. بدیهی است در این صورت بعد از هر آمدن پاسخ از سمت سرور (response)، این کدها بایستی تکرار شوند.
جهت پرهیز از این کدهای تکراری، میتوان برای ماژول Http، یک interceptor واحد درنظر گرفت که تمامی کدهای تکراری را تنها یکبار داخل آن پیاده سازی کرد. مزیت این روش، مدیریت راحت کد، کاهش پیچیدگیها و همچنین حذف کدهای تکراری و یکسان سازی آنها است.
هرچند در Angular دیگر به مانند Angular 1.x مفهوم intercept بر روی Http را به صورت توکار نداریم، ولی به دلایل زیر ما نیاز به پیاده سازی interceptor برای ماژول Http را داریم:
- تنظیم هدرهای سفارشی و اصلاح آدرس، قبل از ارسال درخواست به سمت سرور
- تنظیم token در هدر درخواست، جهت اعتبار سنجی
- مدیریت سراسری خطاهای Http
- انجام هرگونه عملیات crosscutting
حالا که Angular مفهموم intercept را برای ماژول Http خود به صورت توکار درنظر نگرفته است، راهحل چیست؟ بهترین راهحل برای پیاده سازی موارد مطرح شده در بالا، ارث بری و یا گسترش (extend) مستقیم ماژول Http است:
تمامی افعال Http، از جمله get ،post ،put ،delete ،patch ،head و options در نهایت از متد request موجود در ماژول http برای ارسال درخواست خود استفاده میکنند. به همین جهت تمامی عملیات crosscutting را در این متد پیاده سازی کردهایم. به علاوه قبل از ارسال درخواست، توسط متد updateUrl آدرس url خود را اصلاح کردهایم. همچنین توسط متد getRequestOptionArgs هدر درخواست را جهت اعتبار سنجی مقداردهی کردهایم. در اینجا بعد از ارسال درخواست و آمدن response از سمت سرور، توسط catch خطاهای احتمالی را برسی کردهایم.
نکته: به عنوان مثال، در صورتیکه قصد دارید، برای درخواستهایی از جنس get، هدر متفاوتی نسبت به دیگر درخواستها داشته باشید، آنگاه پیاده سازی عملیات اصلاح هدر در متد request جواب کار را نخواهد داد. برای حل این موضوع میتوانید به جای اصلاح header در متد request، تمامی متدهای get ،post، put ،delete ،patch ،head و options را باز نویسی کرده و در هرکدام از این متدها اینکار را انجام دهید.
حالا با تغییر قسمت providers در ماژول اصلی برنامه به شکل زیر، Angular را مجبور میکنیم بجای استفاده از ماژول Http توکار خود، از ماژول جدید InterceptedHttp استفاده کند:
همه چیز آماده است. اکنون کافی است ماژول Http را در سرویس یا کامپوننتهای خود تزریق کرده و درخواستهای Http را بدون هیچگونه نوشتن کد اضافی برای تنظیم هدر و غیره (با فرض اینکه تمامی آنها در متد request از ماژول http نوشته شدهاند)، به مانند قبل صادر کنید. برای نمونه کد زیر را ببینید.
با اینکه Angular از interceptor پشتیبانی نمیکند، ولی کتابخانههایی برای ایجاد قابلیت مشابه interceptor به وجود آمدهاند که برخی از آنها عبارتند از: angular2-cool-http ، ng2-http-interceptor ، ng2-interceptors . به جای extend مستقیم ماژول Http توسط خودتان، اینکار را میتوانید به این کتابخانهها بسپارید.
برای مثال در صورتیکه در برنامه خود از اعتبار سنجی مبتنی بر توکن (Token Base Authentication) استفاده میکنید، قبل از ارسال هر درخواست (request)، کدهایی مشابه کد زیر باید نوشته شوند:
let headers = new Headers(); let token = localStorage.getItem('token'); headers.append('Authorization', 'bearer ' + token); this.http.get('/api/controller/action', { headers: headers })
همچنین فرض کنید بعد از رسیدن جواب هر درخواست، میخواهید response code را چک کنید و خطاهای احتمالی را مدیریت کنید. مثلا درصورت دریافت کد 401، کاربر را به صفحه «ورود» و با دریافت کد 404 آنرا را به صفحه «یافت نشد» هدایت کنید و یا با دریافت کد 403 یا 500 پیغام مناسبی را نمایش دهید. بدیهی است در این صورت بعد از هر آمدن پاسخ از سمت سرور (response)، این کدها بایستی تکرار شوند.
جهت پرهیز از این کدهای تکراری، میتوان برای ماژول Http، یک interceptor واحد درنظر گرفت که تمامی کدهای تکراری را تنها یکبار داخل آن پیاده سازی کرد. مزیت این روش، مدیریت راحت کد، کاهش پیچیدگیها و همچنین حذف کدهای تکراری و یکسان سازی آنها است.
هرچند در Angular دیگر به مانند Angular 1.x مفهوم intercept بر روی Http را به صورت توکار نداریم، ولی به دلایل زیر ما نیاز به پیاده سازی interceptor برای ماژول Http را داریم:
- تنظیم هدرهای سفارشی و اصلاح آدرس، قبل از ارسال درخواست به سمت سرور
- تنظیم token در هدر درخواست، جهت اعتبار سنجی
- مدیریت سراسری خطاهای Http
- انجام هرگونه عملیات crosscutting
حالا که Angular مفهموم intercept را برای ماژول Http خود به صورت توکار درنظر نگرفته است، راهحل چیست؟ بهترین راهحل برای پیاده سازی موارد مطرح شده در بالا، ارث بری و یا گسترش (extend) مستقیم ماژول Http است:
import { Injectable } from "@angular/core"; import { ConnectionBackend, RequestOptions, Request, RequestOptionsArgs, Response, Http, Headers } from "@angular/http"; import { Observable } from "rxjs/Rx"; import 'rxjs/add/operator/catch'; import 'rxjs/add/observable/throw'; @Injectable() export class InterceptedHttp extends Http { constructor(backend: ConnectionBackend, defaultOptions: RequestOptions) { super(backend, defaultOptions); } request(url: string | Request, options?: RequestOptionsArgs): Observable<Response> { // اصلاح url if (typeof (url) === 'string') url = this.updateUrl((url as string)); else url.url = this.updateUrl((url as Request).url); return super.request(url, this.getRequestOptionArgs(options)).catch((err: Response) => { // Exception handling switch (err.status) { case 400: console.log('interceptor: 400'); console.log(err); break; case 404: console.log('interceptor: 404'); console.log(err); break; case 500: console.log('interceptor: 500'); console.log(err); break; case 401: console.log('interceptor: 401'); console.log(err); break; case 403: console.log('interceptor: 403'); console.log(err); break; default: console.log('interceptor: ' + err.status); console.log(err); } return Observable.throw(err); }); } private updateUrl(req: string) { return `http://localhost:61366/api/${req}` } private getRequestOptionArgs(options?: RequestOptionsArgs): RequestOptionsArgs { if (options == null) { options = new RequestOptions(); } if (options.headers == null) { options.headers = new Headers(); } // هدر درخواست تنظیم let token = localStorage.getItem('token'); options.headers.append('Authorization', 'bearer ' + token); return options; } }
نکته: به عنوان مثال، در صورتیکه قصد دارید، برای درخواستهایی از جنس get، هدر متفاوتی نسبت به دیگر درخواستها داشته باشید، آنگاه پیاده سازی عملیات اصلاح هدر در متد request جواب کار را نخواهد داد. برای حل این موضوع میتوانید به جای اصلاح header در متد request، تمامی متدهای get ،post، put ،delete ،patch ،head و options را باز نویسی کرده و در هرکدام از این متدها اینکار را انجام دهید.
حالا با تغییر قسمت providers در ماژول اصلی برنامه به شکل زیر، Angular را مجبور میکنیم بجای استفاده از ماژول Http توکار خود، از ماژول جدید InterceptedHttp استفاده کند:
//… providers: [{ provide: Http, useFactory: (backend: XHRBackend, options: RequestOptions) => { return new InterceptedHttp(backend, options); }, deps: [XHRBackend, RequestOptions], }], //…
همه چیز آماده است. اکنون کافی است ماژول Http را در سرویس یا کامپوننتهای خود تزریق کرده و درخواستهای Http را بدون هیچگونه نوشتن کد اضافی برای تنظیم هدر و غیره (با فرض اینکه تمامی آنها در متد request از ماژول http نوشته شدهاند)، به مانند قبل صادر کنید. برای نمونه کد زیر را ببینید.
import { Http, URLSearchParams } from '@angular/http'; //… constructor(private _http: Http) { } ngOnInit() { let urlSearchParams: URLSearchParams = new URLSearchParams(); urlSearchParams.append('page', page.toString()); urlSearchParams.append('count', count.toString()); let params = urlSearchParams.toString(); this._http.get(`/cars`, { params: params }) .subscribe(result => { console.log('service: Succ'); this.cars = result.json(); }, err => { console.log('service: error'); }); } //…
آیا این امکان هست که یکی از پارامتر هارو نمایش ندیم مثلا به این صورت بشه
من این تغییر رو ایجاد کردم و میخوام مقدار issueId رو نمایش ندم اصلا اما url ساخته شده این شکلی میشه
url: "Details/{projectId}"
@Html.ActionLink("detail","Details",new {issueId=10,projectId=11})
http://localhost:2435/Home/Details?issueId=10&projectId=11
نظرات مطالب
ASP.NET MVC #9
با سلام
نحوه استفاده از ActionLink برای چند پارامتر چگونه است . در صورتی که در Array آیتم بعدی را اضافه کنیم به صورت ؟ و یک queryString تبدیل میشود . در صورتی که بخواهیم به صورت یک / پارامترهای بعدی را مقدار دهی کنیم به چه صورت است ؟
نحوه استفاده از ActionLink برای چند پارامتر چگونه است . در صورتی که در Array آیتم بعدی را اضافه کنیم به صورت ؟ و یک queryString تبدیل میشود . در صورتی که بخواهیم به صورت یک / پارامترهای بعدی را مقدار دهی کنیم به چه صورت است ؟
@Html.ActionLink(item.Name, "Details", new { id = item.ProductNumber , Name=item.Name })
http://localhost/Products/Details/D123?Name=Super%20Fast%20Bike
به این صورت تبدیل شود
http://localhost/Products/Details/D123/Super%20Fast%20Bike
به این صورت تبدیل شود
http://localhost/Products/Details/D123/Super%20Fast%20Bike
با تشکر
مطالب
آشنایی اولیه با gRPC
در مقالهی قبلی بطور کلی با Protocol Buffers آشنا شدیم. در این قسمت با gRPC آشنا شده و همچنین به پیاده سازی یک سرور و کلاینت، با استفاده از gRPC پرداخته که توسط آن به تبادل اطلاعات با یکدیگر میپردازند.
مدل و سرویسها بصورت واضحی نوشته شدهاند؛ SayHello با ورودی HelloRequest و خروجی HelloReply تعیین شدهاست.
از طریق Grpc.Tools میتوانیم protobufهای خود را بصورت خودکار بعد از build تولید نماییم. در csproj آیتم زیر را اضافه کرده و آدرس protobuf را تعیین مینماییم.
حال کافی است کدهای زیر را جایگزین نماییم:
همانطور که مشاهده میکنید، مدلها و سریسها بصورت خودکار تولید شدهاند (ضمن اینکه میتوانستیم بصورت دستی نیز protobuf را برای زبان دلخواه خود تولید نماییم).
فرض کنید فایل generate شده در پوشهی proto قرار گرفته به نام "helloworld.pb.go"
gRPC یک فریم ورک مدرن و متن باز با کارآیی بالاست. توسط گوگل پیاده سازی شده و جزء انجمن CNCF میباشد (مثل Docker & Kubernetes) که بر روی سیستم عاملهای متعددی اجرا میشود. به صورت خیلی کارا میتواند سرویسهای متعددی را به یکدیگر متصل کرده و همچنین از امکاناتی همچون load balancing, monitoring, tracing, health checking, authentication به صورت خیلی ساده پشتیبانی میکند. بسایر سریع و همچنین Low Latency است. مستقل از یک زبان برنامه نویسی خاص هست و برای streaming بسیار مناسب است و همچنین برای سیستمهای توزیع شده پیشنهاد میشود و به راحتی قابل توسعه و نگهداری است.
راجع به مزایای gRPC بسیار صحبت کردیم. برای طراحی سرویسهای متعددی که با یکدیگر در ارتباط هستند، مناسب میباشد. از HTTP/2 به صورت پیشفرض استفاده میکند (راجع به تفاوت HTTP/2 و HTTP1 اینجا را مطالعه بفرمایید).
شاید بزرگترین مشکلی که در حال حاضر دارد این است که REST را پشتیبانی نمیکند. بدین معنا که شما از طریق browser نمیتوانید یک در خواست را به یک سرور پیاده سازی شده توسط gRPC بصورت مستقیم ارسال کنید. راه حل اول برای حل این مشکل، پیاده سازی یک restful gateway با ابزار دلخواه خود و بقیه سرویسها بعد از آن به هم از طریق gRPC ارتباط برقرا میکنند، یا راه حل بهتر اینکه از grpc-gateway استفاده شود. ابزاری است که به کمک آن میتوانید سیستم خود را با REST یکپارچه سازی نمایید (هر چند راههای دیگری برای وصل شدن از مرورگر به یک سرور gRPC با استفاده از کتابخانههای third party میسر شده، اما خارج از موضوع بحث است و مطالعهی بیشتر را به خواننده واگذار میکنم)
قدم اول در پیاده سازی یک سرور/کلاینت با استفاده از gRPC، آشنایی با protocol buffers هست. برای آشنایی، به مقالهی قبلی رجوع فرمایید. تمامی پیاده سازیهای ما از روی کدهای تولید شده از تعاریف protocol bufferهایی هست که نوشتهایم.
حال فرض کنید میخواهیم یک سرور gRPC را با استفاده از #C نوشته و پیاده سازی نماییم:
۱) قدم اول قطعا نوشتن protobuf میباشد. همانطور که در مقالهی قبلی ذکر شده است، به صورت زیر، مدل و همچنین متدهای لازم را معرفی مینماییم و نام آن را helloworld.proto قرار میدهیم.
syntax = "proto3"; package helloworld; service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} } message HelloRequest { string name = 1; } message HelloReply { string message = 1; }
۲) حالا کافی است یک پروژهی Console را ساخته و ابتدا پکیجهای زیر را نصب نماییم.
Google.Protobuf grpc Grpc.Tools
<ItemGroup> <Protobuf Include="helloworld.proto" /> </ItemGroup>
using System; using System.Collections.Generic; using System.Threading.Tasks; using Helloworld; using Grpc.Core; namespace ServerGrpc { class GreeterImpl : Greeter.GreeterBase { public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context) { System.Console.WriteLine("request made!"); return Task.FromResult(new HelloReply { Message = "Hello " + request.Name }); } } class Program { const int Port = 50051; public static void Main(string[] args) { Server server = new Server { Services = { Greeter.BindService(new GreeterImpl()) }, Ports = { new ServerPort("localhost", Port, ServerCredentials.Insecure) } }; server.Start(); Console.WriteLine("Greeter server listening on port " + Port); Console.WriteLine("Press any key to stop the server..."); Console.ReadKey(); server.ShutdownAsync().Wait(); } } }
سرور را بر روی پورت مشخصی ایجاد کرده و همچنین سرویس مورد نظرمان را پیاده سازی کردهایم؛ به صورت فوق همه چیز به سادهترین صورت در نظر گرفته شده است.
gRPC به صورت خودکار از پروتکل امن ssl استفاده میکند؛ اما برای راحتی کار ما از آن استفاده نکردهایم.
نکته: فایلهای generate شده را از طریق آدرس زیر میتوانید پیدا کنید:
obj/Debug/netcoreapp2.2(یا نسخهی دیگری که استفاده میکنید)
حالا بنا داریم یک کلاینت را با یک زبان برنامه نویسی کاملا مجزا نوشته و به سرور grpc متصل شویم. این کلاینت را با زبان Go خواهیم نوشت (بدیهی است میتوان جای زبانهای برنامه نویسی کلاینت و سرور را تغییر داد).
نکته: خیلی وارد جزیات زبان Go نمیشویم و فقط اشارهای به موارد کلی خواهیم کرد.
ابتدا باید از روی protobuf کد مربوط به Go را تولید نماییم؛ به صورت زیر:
protoc helloworld.proto --go_out=plugins=grpc:.
یک فایل به نام main.go ساخته و کدهای زیر را وارد مینماییم.
package main import ( "fmt" "golang.org/x/net/context" "google.golang.org/grpc" "gosample/proto" ) func main() { initial() } func initial(){ conn, _ := grpc.Dial("localhost:50051", grpc.WithInsecure()) defer conn.Close() client := helloworld.NewGreeterClient(conn) data, _ := client.SayHello(context.Background(), &helloworld.HelloRequest{Name : "Ali"}) fmt.Println(data) }
به سرور به صورت insecure متصل شده ایم؛ آخر برنامه connection را میبندیم و SayHello را فراخوانی کرده و جواب را بر روی خروجی نمایش میدهیم.
نکته: gosample اسم پروژهای است که من ساختهام و proto آدرس پوشهای است که فایل تولید شدهی grpc داخل آن قرار گرفتهاست؛ بقیه نیز کتابخانههای لازم برای کار با grpc میباشد.
نکته: gRPC برای streaming دیتا بسیار مناسب است (هم یکطرفه و همینطور دو طرفه).
نکته: به دلیل سادگی کار با ابزارهای مختلف، انتخاب خیلی خوبی برای سیستمهای توزیع شدهاست؛ همانطور که مشاهده کردید به راحتی قابلیت تعامل بین زبانهای برنامه نویسی متعددی برقرار است.
نکتهی آخر: از وارد شدن به موارد ریز اجتناب کردهام و صرفا این مقاله جهت آشنایی و دید کلی نسبت به این موضوع در نظر گرفته شدهاست.
نظرات اشتراکها
کجا می توانیم از Task.WhenAll استفاده کنیم و چگونه؟
هنگام استفاده از این متد نیاز به رعایت یکسری نکات ویژه هست؛ وگرنه مشکل ساز میشود.
نظرات اشتراکها
شبکه اجتماعی فیس نما هک شد
اشتراکها