// ASPX page <telerik:RadGrid ID="RadGrid1" runat="server"></telerik:RadGrid> // Asp.Net Code Behind protected void Page_Load(object sender, EventArgs e) { GridPresenter presenter = new GridPresenter(this); } // view interface public interface IGridView { Telerik.Web.UI.RadGrid myGrid { get; } } // presenter protected readonly IGridView _view; public GridPresenter(IGridView view) { _view = view; _view.myGrid.UpdateCommand += new Telerik.Web.UI.GridCommandEventHandler(onUpdateCommand); _view.myGrid.InsertCommand += new Telerik.Web.UI.GridCommandEventHandler(onInsertCommand); _view.myGrid.EditCommand += new Telerik.Web.UI.GridCommandEventHandler(onEditCommand); } private void onUpdateCommand(object sender, Telerik.Web.UI.GridCommandEventArgs e) { // Code for updating } private void onInsertCommand(object sender, Telerik.Web.UI.GridCommandEventArgs e) { // Code for inserting } private void onEditCommand(object sender, Telerik.Web.UI.GridCommandEventArgs e) { // Code for editcommand }
Blazor 5x - قسمت هفتم - مبانی Blazor - بخش 4 - انتقال اطلاعات از کامپوننتهای فرزند به کامپوننت والد
در این تصویر، checkboxهای انتخاب شده، درون کامپوننتهای مجزای فرزند و گزارش جمع نهایی ارائه شده، در کامپوننت والد قرار دارند.
معرفی Event Call Back
در این قسمت قصد داریم به کامپوننت Pages\LearnBlazor\LearnBlazorComponents\IndividualRoom.razor که در مثال این سری تکمیل کردیم، یک checkbox انتخاب را نیز اضافه کنیم تا کاربرها بتوانند در زمان نمایش لیست اتاقها در کامپوننت Pages\LearnBlazor\DemoHotel.razor، بیش از یک اتاق را انتخاب کنند.
برای این منظور در ابتدا به کامپوننت DemoHotel مراجعه کرده و فیلد SelectedRooms را در آن تعریف کرده و ذیل عنوان Hotel Rooms نمایش میدهیم:
@page "/demoHotel" <div class="col-12"> <h4 class="text-info">Hotel Rooms</h4> <span>Rooms Selected - @SelectedRooms</span> </div> @foreach (var room in Rooms) { <IndividualRoom Room="room"></IndividualRoom> } @code{ int SelectedRooms; void RoomSelectionCounterChanged(bool isRoomSelected) { if (isRoomSelected) { SelectedRooms++; } else { SelectedRooms--; } } // ... }
در ادامه به کامپوننت IndividualRoom.razor مراجعه کرده و کدهای آن را به صورت زیر تغییر میدهیم:
<input type="checkbox" @onchange="RoomCheckBoxSelectionChanged" /> @code { //... [Parameter] public EventCallback<bool> OnRoomCheckBoxSelection { get; set; } async Task RoomCheckBoxSelectionChanged(ChangeEventArgs e) { await OnRoomCheckBoxSelection.InvokeAsync((bool)e.Value); } }
تا اینجا فقط یک رخداد را به یک متد، در همان کامپوننت متصل کردهایم. هربار که checkbox تعریف شده انتخاب شود، متد رویدادگردان RoomCheckBoxSelectionChanged اجرا میشود. مرحلهی بعد، انتقال اطلاعات آن، به کامپوننت والد است که اینکار توسط پارامتر OnRoomCheckBoxSelection صورت میگیرد. کار آن، انتقال وضعیت checkbox، به متد RoomSelectionCounterChanged کامپوننت والد است.
بنابراین در اینجا نیاز است تا بتوان ارجاعی از این متد کامپوننت والد را به کامپوننت فرزند ارسال کرد که EventCallback تعریف شدهی به صورت پارامتر، چنین هدفی را برآورده میکند. با پارامتر تعریف شدن آن، میتوان OnRoomCheckBoxSelection را به صورت زیر، به هر المان تعریف کنندهی کامپوننت IndividualRoom در کامپوننت DemoHotel اضافه کرد:
@foreach (var room in Rooms) { <IndividualRoom OnRoomCheckBoxSelection="RoomSelectionCounterChanged" Room="room"></IndividualRoom> }
بنابراین به صورت خلاصه، هر زمانیکه یک checkbox در کامپوننت IndividualRoom انتخاب میشود، در نتیجهی آن متد منتسب به EventCallback ارسالی به آن کامپوننت نیز فراخوانی میگردد که اینکار، سبب اجرای کدی در کامپوننت والد خواهد شد.
یک تمرین: انتقال رویداد انتخاب شدن یک div به کامپوننت والد
در بخش 2، در انتهای مطلب، لیست امکانات رفاهی هتل را هم نمایش دادیم. در اینجا میخواهیم اگر کاربری بر روی خروجی کامپوننت یکی از امکانات موجود کلیک کرد (کلیک بر روی div آن)، نام آن ویژگی در کامپوننت والد نمایش داده شود.
برای این منظور کامپوننت Pages\LearnBlazor\LearnBlazorComponents\IndividualAmenity.razor را به صورت زیر تغییر میدهیم:
<div class="bg-light border p-2 col-5 offset-1 mt-2" @onclick="args => AmenitySelectionChanged(args, Amenity.Name)"> <h4 class="text-secondary">Amenity - @Amenity.Id</h4> @Amenity.Name<br /> @Amenity.Description<br /> </div> @code { [Parameter] public BlazorAmenity Amenity { get; set; } [Parameter] public EventCallback<string> OnAmenitySelection { get; set; } protected async Task AmenitySelectionChanged(MouseEventArgs e, string name) { await OnAmenitySelection.InvokeAsync(name); } }
در اینجا نیاز خواهیم داشت تا اطلاعات رشتهای نام Amenity جاری را پس از کلیک بر روی div، به کامپوننت والد انتقال دهیم و MouseEventArgs فقط به همراه اطلاعات مختصات محل قرارگیری اشارهگر ماوس است. در یک چنین حالتی میتوان با استفاده از anonymous method زیر، امضای متد منتسب به آنرا تغییر داد:
@onclick="args => AmenitySelectionChanged(args, Amenity.Name)"
@page "/demoHotel" @foreach (var amenity in AmenitiesList) { <IndividualAmenity OnAmenitySelection="AmenitySelectionChanged" Amenity="amenity"></IndividualAmenity> } <div class="col-12"> <p class="text-secondary"> Selected Amenity : @SelectedAmenity </p> </div> @code{ string SelectedAmenity = ""; void AmenitySelectionChanged(string amenity) { SelectedAmenity = amenity; } }
سپس این پارامتر رشتهای دریافتی، به فیلد جدید SelectedAmenity انتساب داده میشود که پس از پایان این متد و رویداد، سبب درج آن در زیر حلقهی نمایش AmenitiesList خواهد شد:
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: Blazor-5x-Part-07.zip
برای قسمت backend، از همان برنامهی تکمیل شدهی قسمت قبل استفاده میکنیم که به آن تولید مقدماتی JWTها نیز اضافه شدهاست. البته این سری، مستقل از قسمت سمت سرور آن تهیه خواهد شد و صرفا در حد دریافت توکن از سرور و یا ارسال مشخصات کاربر جهت لاگین، نیاز بیشتری به قسمت سمت سرور آن ندارد و تاکید آن بر روی مباحث سمت کلاینت React است. بنابراین اینکه چگونه این توکن را تولید میکنید، در اینجا اهمیتی ندارد و کلیات آن با تمام روشهای پیاده سازی سمت سرور سازگار است (و مختص به فناوری خاصی نیست). پیشنیاز درک کدهای سمت سرور قسمت JWT آن، مطالب زیر هستند:
- «معرفی JSON Web Token»
- «اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity»
- «پیاده سازی JSON Web Token با ASP.NET Web API 2.x»
- « آزمایش Web APIs توسط Postman - قسمت ششم - اعتبارسنجی مبتنی بر JWT»
ثبت یک کاربر جدید
فرم ثبت نام کاربران را در قسمت 21 این سری، در فایل src\components\registerForm.jsx، ایجاد و تکمیل کردیم. البته این فرم هنوز به backend server متصل نیست. برای کار با آن هم نیاز است شیءای را با ساختار زیر که ذکر سه خاصیت اول آن اجباری است، به endpoint ای با آدرس https://localhost:5001/api/Users به صورت یک HTTP Post ارسال کنیم:
{ "name": "string", "email": "string", "password": "string", "isAdmin": true, "id": 0 }
اکنون نوبت به اتصال کامپوننت registerForm.jsx، به سرویس backend است. تا اینجا دو سرویس src\services\genreService.js و src\services\movieService.js را در قسمت قبل، به برنامه جهت کار کردن با endpointهای backend server، اضافه کردیم. شبیه به همین روش را برای کار با سرویس سمت سرور api/Users نیز در پیش میگیریم. بنابراین فایل جدید src\services\userService.js را با محتوای زیر، به برنامهی frontend اضافه میکنیم:
import http from "./httpService"; import { apiUrl } from "../config.json"; const apiEndpoint = apiUrl + "/users"; export function register(user) { return http.post(apiEndpoint, { email: user.username, password: user.password, name: user.name }); }
اطلاعات شیء user ای که در اینجا دریافت میشود، از خاصیت data کامپوننت RegisterForm تامین میگردد:
class RegisterForm extends Form { state = { data: { username: "", password: "", name: "" }, errors: {} };
پس از تعریف userService.js، به registerForm.jsx بازگشته و ابتدا امکانات آنرا import میکنیم:
import * as userService from "../services/userService";
import { register } userService from "../services/userService";
doSubmit = async () => { try { await userService.register(this.state.data); } catch (ex) { if (ex.response && ex.response.status === 400) { const errors = { ...this.state.errors }; // clone an object errors.username = ex.response.data; this.setState({ errors }); } } };
در این حالت برای ارسال اطلاعات یک کاربر، در بار اول، یک چنین خروجی را از سمت سرور میتوان شاهد بود که id جدیدی را به این رکورد نسبت دادهاست:
اگر مجددا همین رکورد را به سمت سرور ارسال کنیم، اینبار خطای زیر را دریافت خواهیم کرد:
که از نوع 400 یا همان BadRequest است:
بنابراین نیاز است بدنهی response را در یک چنین مواردی که خطایی از سمت سرور صادر میشود، دریافت کرده و با به روز رسانی خاصیت errors در state فرم (همان قسمت بدنهی catch کدهای فوق)، سبب درج و نمایش خودکار این خطا شویم:
پیشتر در قسمت بررسی «کار با فرمها» آموختیم که برای مدیریت خطاهای پیش بینی شدهی دریافتی از سمت سرور، نیاز است قطعه کدهای مرتبط با سرویس http را در بدنهی try/catchها محصور کنیم. برای مثال در اینجا اگر ایمیل شخصی تکراری وارد شود، سرویس یک return BadRequest("Can't create the requested record.") را بازگشت میدهد که در اینجا status code معادل BadRequest، همان 400 است. بنابراین انتظار داریم که خطای 400 را از سمت سرور، تحت شرایط خاصی دریافت کنیم. به همین دلیل است که در اینجا تنها مدیریت status code=400 را در بدنهی catch نوشته شده ملاحظه میکنید.
سپس برای نمایش آن، نیاز است خاصیت متناظری را که این خطا به آن مرتبط میشود، با پیام دریافت شدهی از سمت سرور، مقدار دهی کنیم که در اینجا میدانیم مرتبط با username است. به همین جهت سطر errors.username = ex.response.data، کار انتساب بدنهی response را به خاصیت جدید errors.username انجام میدهد. در این حالت اگر به کمک متد setState، کار به روز رسانی خاصیت errors موجود در state را انجام دهیم، رندر مجدد فرم، در صف انجام قرار گرفته و در رندر بعدی آن، پیام موجود در errors.username، نمایش داده میشود.
پیاده سازی ورود به سیستم
فرم ورود به سیستم را در قسمت 18 این سری، در فایل src\components\loginForm.jsx، ایجاد و تکمیل کردیم که این فرم نیز هنوز به backend server متصل نیست. برای کار با آن نیاز است شیءای را با ساختار زیر که ذکر هر دو خاصیت آن اجباری است، به endpoint ای با آدرس https://localhost:5001/api/Auth/Login به صورت یک HTTP Post ارسال کنیم:
{ "email": "string", "password": "string" }
var jwt = _tokenFactoryService.CreateAccessToken(user); return Ok(new { access_token = jwt });
در ادامه برای تعامل با منبع api/Auth/Login سمت سرور، ابتدا یک سرویس مختص آنرا در فایل جدید src\services\authService.js، با محتوای زیر ایجاد میکنیم:
import { apiUrl } from "../config.json"; import http from "./httpService"; const apiEndpoint = apiUrl + "/auth"; export function login(email, password) { return http.post(apiEndpoint + "/login", { email, password }); }
import * as auth from "../services/authService"; class LoginForm extends Form { state = { data: { username: "", password: "" }, errors: {} }; // ... doSubmit = async () => { try { const { data } = this.state; const { data: { access_token } } = await auth.login(data.username, data.password); console.log("JWT", access_token); localStorage.setItem("token", access_token); this.props.history.push("/"); } catch (ex) { if (ex.response && ex.response.status === 400) { const errors = { ...this.state.errors }; errors.username = ex.response.data; this.setState({ errors }); } } };
- ابتدا تمام خروجیهای ماژول authService را با نام شیء auth دریافت کردهایم.
- سپس در متد doSubmit، اطلاعات خاصیت data موجود در state را که معادل فیلدهای فرم لاگین هستند، به متد auth.login برای انجام لاگین سمت سرور، ارسال کردهایم. این متد چون یک Promise را باز میگرداند، باید await شود و پس از آن متد جاری نیز باید به صورت async معرفی گردد.
- همانطور که عنوان شد، خروجی نهایی متد auth.login، یک شیء JSON دارای خاصیت access_token است که در اینجا از خاصیت data خروجی نهایی دریافت شدهاست.
- سپس نیاز است برای استفادههای آتی، این token دریافتی از سرور را در جایی ذخیره کرد. یکی از مکانهای متداول اینکار، local storage مرورگرها است (اطلاعات بیشتر).
- در آخر کاربر را توسط شیء history سیستم مسیریابی برنامه، به صفحهی اصلی آن هدایت میکنیم.
- در اینجا قسمت catch نیز ذکر شدهاست تا خطاهای حاصل از return BadRequestهای دریافتی از سمت سرور را بتوان ذیل فیلد نام کاربری نمایش داد. روش کار آن، دقیقا همانند روشی است که برای فرم ثبت یک کاربر جدید استفاده کردیم.
اکنون اگر برنامه را ذخیره کرده و اجرا کنیم، توکن دریافتی، در کنسول توسعه دهندگان مرورگر لاگ شده و سپس کاربر به صفحهی اصلی برنامه هدایت میشود. همچنین این token ذخیره شده را میتوان در ذیل قسمت application->storage آن نیز مشاهده کرد:
لاگین خودکار کاربر، پس از ثبت نام در سایت
پس از ثبت نام یک کاربر در سایت، بدنهی response بازگشت داده شدهی از سمت سرور، همان شیء user است که اکنون Id او مشخص شدهاست. بنابراین اینبار جهت ارائهی token از سمت سرور، بجای response body، از یک هدر سفارشی در فایل Controllers\UsersController.cs استفاده میکنیم (کدهای کامل آن در انتهای بحث پیوست شدهاست):
var jwt = _tokenFactoryService.CreateAccessToken(user); this.Response.Headers.Add("x-auth-token", jwt);
در ادامه در کدهای سمت کلاینت src\components\registerForm.jsx، برای استخراج این هدر سفارشی، اگر شیء response دریافتی از سرور را لاگ کنیم:
const response = await userService.register(this.state.data); console.log(response);
برای اینکه در کدهای سمت کلاینت بتوان این هدر سفارشی را خواند، نیاز است هدر مخصوص access-control-expose-headers را نیز به response اضافه کرد:
var jwt = _tokenFactoryService.CreateAccessToken(data); this.Response.Headers.Add("x-auth-token", jwt); this.Response.Headers.Add("access-control-expose-headers", "x-auth-token");
اکنون میتوان این هدر سفارشی را در متد doSubmit کامپوننت RegisterForm، از طریق شیء response.headers خواند و در localStorage ذخیره کرد. سپس کاربر را توسط شیء history سیستم مسیریابی، به ریشهی سایت هدایت نمود:
class RegisterForm extends Form { // ... doSubmit = async () => { try { const response = await userService.register(this.state.data); console.log(response); localStorage.setItem("token", response.headers["x-auth-token"]); this.props.history.push("/"); } catch (ex) { if (ex.response && ex.response.status === 400) { const errors = { ...this.state.errors }; // clone an object errors.username = ex.response.data; this.setState({ errors }); } } };
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: sample-26-backend.zip و sample-26-frontend.zip
در قسمت اول با مفاهیم اولیه Class و Object آشنا شدیم.
Messages and Methods
Objectها باید مانند ماشینهایی تلقی شوند که عملیات موجود در واسط عمومی خود را برای افرادی که درخواست مناسبی ارسال کنند، اجرا خواهند کرد. با توجه به اینکه یک object از استفاده کننده خود مستقل است و وابستگی به او ندارد و همچنین توجه به ساختار نحوی (syntax) برخی از زبانهای شیء گرای جدید، عبارت «sending a message» برای توصیف اجرای رفتاری از مجموعه رفتارهای object، استفاده میشود.
به محض اینکه پیغامی (Message) به سمت object ارسال شود، ابتدا باید تصمیم بگیرد که این پیغام ارسالی را درک میکند. فرض کنیم این پیغام قابل درک است. در این صورت object مورد نظر، همزمان با نگاشت پیغام به یک فراخوانی تابع (function call)، خود را به صورت ضمنی به عنوان اولین آرگومان ارسال میکند. تصمیم گرفتن در رابطه با قابل درک بودن یک پیغام، در زبانهای مفسری در زمان اجرا و در زبانهای کامپایلری در زمان کامپایل، انجام میگرد.
نام (یا prototype) رفتار یک وهله، Message (پیغام) نامیده میشود. بسیاری از زبانهای شیء گرا مفهموم Overloaded Functions Or Operators را پشتیبانی میکنند. در این صورت میتوان در سیستم دو تابعی داشت که با نام یکسان، یا انواع مختلف آرگومان (intraclass overloading) داشته باشند یا در کلاسهای مختلفی (interclass overloading) قرار گیرند.
ممکن است کلاس ساعت زنگدار، دو پیغام set_time که یکی از آنها با دو آرگومان از نوع عدد صحیح و دیگری یک آرگومان رشتهای است داشته باشد.
void AlarmClock::set_time(int hours, int minutes); void AlarmClock::set_time(String time);
در مقابل، کلاس ساعت زنگدار و کلاس ساعت مچی هر دو messageای به نام set_time با دو آرگومان از نوع عدد صحیح دارند.
void AlarmClock::set_time(int hours, int minutes); void Watch::set_time(int hours, int minutes);
باید توجه کنید که یک پیغام، شامل نام تابع، انواع آرگومان، نوع بازگشتی و کلاسی که پیغام به آن متصل است، میباشد. این اطلاعاتی که مطرح شد، بخش اصلی چیزی است که کاربر یک کلاس نیاز دارد در مورد آنها آگاهی داشته باشد.
در برخی از زبانها و یا سیستمها، اطلاعات دیگری مانند: انواع استثناءهایی که از سمت پیغام پرتاب میشوند تا اطلاعات همزمانی (پیغام به صورت همزمان است یا ناهمزمان) را برای استفاده کننده مهیا کنند. از طرفی پیاده سازی کنندگان یک کلاس باید از پیاده سازی پیغام آگاه باشند. جزئیات پیاده سازی یک پیغام -کدی که پیغام را پیاده سازی میکند- Method (متد) نامیده میشود. آنگاه که نخ (thread) کنترل درون متد باشد، برای مشخص کردن اینکه پیغام رسیده برای کدام وهله ارسال شدهاست، ارجاعی به وهله مورد نظر و به عنوان اولین آرگومان، به صورت ضمنی ارسال میشود. این آرگومان ضمنی، در بیشتر زبانها Self Object نامیده میشود (در سی پلاس پلاس this object نام دارد). در نهایت، مجموعه پیغامهایی که یک وهله میتواند به آنها پاسخ دهد، Protocol (قرارداد) نام دارد.
دو پیغام خاصی که کلاسها یا وهلهها میتوانند به آنها پاسخ دهند، اولی که استفاده کنندگان کلاس برای ساخت وهلهها از آن استفاده میکنند، Constructor (سازنده) نام دارد. هر کلاسی میتواند سازندههای متعددی داشته باشد که هر کدام مجموعه پارامترهای مختلفی را برای مقدار دهی اولیه میپذیرند. دومین پیغام، عملیاتی است که وهله را قبل از حذف از سیستم، پاک سازی میکند. این عملیات، Destructor (تخریب کننده) نام دارد. بیشتر زبانهای شیء گرا، برای هر کلاس تنها یک تخریب کننده دارند. این پیغامها را به عنوان مکانیزم مقدار دهی اولیه و پاک سازی در پارادایم شیء گرا در نظر بگیرید.
قاعده شهودی 2.2
استفاده کنندگان از کلاس باید به واسط عمومی آن وابسته باشند، اما یک کلاس نباید به استفاده کنندگان خود، وابسته باشد. (Users of a class must be dependent on its public interface, but a class should not be dependent on its users)
منطق پشت این قاعده، یکی از شکلهای قابلیت استفاده مجدد (resuability) میباشد. یک ساعت زنگدار ممکن است توسط شخصی در اتاق خواب او استفاده شود. واضح است که شخص مورد نظر به واسط عمومی ساعت زنگدار وابسته میباشد. به هر حال، ساعت زنگدار نباید به شخصی وابسته باشد. اگر ساعت زنگدار به شخصی وابسته باشد، بدون مهیا کردن یک شخص، نمیتوان از آن برای ساخت یک TimeLockSafe استفاده کرد. این وابستگیها برای مواقعیکه میخواهیم امکان این را داشته باشیم تا کلاس ساعت زنگدار را از دامین (domain) خود خارج کرده و در دامین دیگری، بدون وابستگی هایش مورد استفاده قرار دهیم، نامطلوب هستند.
شکل 2.4 The Use Of Alarm Clocks
قاعده شهودی 2.3
تعداد پیغامهای موجود در قرارداد یک کلاس را کمینه سازید. (Minimize the number of messages in the protocol of a class)
چندین سال قبل، مطلبی منتشر شد که کاملا متضاد این قاعده شهودی میباشد. طبق آن، پیاده سازی کننده یک کلاس میتواند یکسری عملیات را با فرض اینکه در آینده مورد استفاده قرار گیرند، برای آن در نظر بگیرد. ایراد این کار چیست؟ اگر شما از این قاعده پیروی کنید، حتما کلاس LinkedList من، توجه شما را جلب خواهد کرد؛ این کلاس در واسط عمومی خود 4000 عملیات را دارد. فرض کنید قصد ادغام دو وهله از این کلاس را داشته باشید. در این صورت حتما فرض شما این است که عملیاتی تحت عنوان merge در این کلاس تعبیه شده است. بعد از جستجوی بین این تعداد عملیات، در نهایت این عملیات خاص را پیدا نخواهید کرد. چراکه این عملیات متأسفانه به صورت یک overloaded plus operator پیاده سازی شده است. مشکل اصلی واسط عمومی با تعداد زیادی عملیات این است که فرآیند یافتن عملیات مورد نظرمان را خیلی سخت یا حتی ناممکن خواهد کرد و مشکلی جدی برای قابلیت استفاده مجدد تلقی میشود.
با کمینه نگه داشتن تعداد عملیات واسط عمومی، سیستم، قابل فهمتر و همچنین مولفههای (components) آن به راحتی قابل استفاده مجدد خواهند بود.
قاعده شهودی 2.4
پیاده سازی یک واسط عمومی یکسان کمینه برای همه کلاسها (Implement a minimal public interface that all classes understand [e.g., operations such as copy (deep versus shallow), equality testing, pretty printing, parsing from an ASCII description, etc.].)
مهیا کردن یک واسط عمومی مشترک کمینه برای کلاسهایی که توسط یک توسعه دهنده پیاده سازی شده و قرار است توسط توسعه دهندگان دیگر مورد استفاده قرار گیرد، خیلی مفید خواهد بود. این واسط عمومی، حداقل عاملیتی را که به طور منطقی از هر کلاس میشود انتظار داشت، مهیا خواهد ساخت. واسطی که میتواند از آن به عنوان مبنای یادگیری درباره رفتارهای کلاسها در پایه نرم افزاری با قابلیت استفاده مجدد، بهره برد.
به عنوان مثال کلاس Object در دات نت به عنوان کلاس پایه ضمنی با یکسری از متدهای عمومی (برای مثال ToString)، نشان دهنده تعریف یک واسط عمومی مشترک برای همه کلاسها در این فریمورک، میباشد.
public class Object { public Object(); public static bool Equals(Object objA, Object objB){...} public static bool ReferenceEquals(Object objA, Object objB){...} public virtual bool Equals(Object obj){...} public virtual int GetHashCode(){...} public Type GetType(){...} public virtual string ToString(){...} protected Object MemberwiseClone(){...} }
قاعده شهودی 2.5
جزئیات پیاده سازی، مانند توابع خصوصی common-code ( توابعی که کد مشترک سایر متدهای کلاس را در بدنه خود دارند) را در واسط عمومی یک کلاس قرار ندهید. (Do not put implementation details such as common-code private functions into the public interface of a class)
این قاعده برای کاهش پیچیدگی واسط عمومی کلاس برای استفاده کنندگان آن، طراحی شده است. ایده اصلی این است که استفاده کنندگان کلاس تمایلی ندارند به اعضایی دسترسی داشته باشند که از آنها استفاده نخواهند کرد؛ این اعضا باید به صورت خصوصی در کلاس قرار داده شوند. این توابع خصوصی common-code، زمانیکه متدهای یک کلاس، کد مشترکی را داشته باشند، ایجاد خواهند شد. قرار دادن این کد مشترک در یک متد، معمولا روش مناسبی میباشد. نکته قابل توجه این است که این متد، عملیات جدیدی نمیباشد؛ بله جزئیات پیاده سازی دو عملیات دیگر از کلاس را ساده کرده است.
شکل 2.5 Example of a common-code private function
مثال واقعی
فرض کنید در شکل بالا، کلاس X معادل یک LinkedList کلاس، f1و f2 به عنوان توابع insert و remove و تابع f به عنوان تابع common-code که عملیات یافتن آدرس را برای درج و حذف انجام میدهد، میباشند.
قاعده شهودی 2.6
واسط عمومی کلاس را با اقلامی که یا استفاده کنندگان از کلاس توانایی استفاده از آن را نداشته و یا تمایلی به استفاده از آنها ندارند، آمیخته نکنید. (Do not clutter the public interface of a class with items that users of that class are not able to use or are not interested in using )
این قاعده شهودی با قاعده قبلی که با قرار دادن تابع common-code در واسط عمومی کلاس، فقط باعث در هم ریختن واسط عمومی شده بود، مرتبط میباشد. در برخی از زبانها مانند C++، برای مثال این امکان وجود دارد که سازنده یک کلاس انتزاعی (abstract) را در واسط عمومی آن قرار دهید؛ حتی با وجود اینکه در زمان استفاده از آن سازنده با خطای نحوی روبرو خواهید شد. این قاعده شهودی کلی، برای کاهش این مشکلات در نظر گرفته شده است.
UI
در نهایت نوبت به طراحی و کدنویسی UI میرسد تا بتوانیم محصولات را به کاربر نمایش دهیم. اما قبل از شروع باید موضوعی را یادآوری کنم. اگر به یاد داشته باشید، در کلاس ProductService موجود در لایهی Domain، از طریق یکی از روشهای الگوی Dependency Injection به نام Constructor Injection، فیلدی از نوع IProductRepository را مقداردهی نمودیم. حال زمانی که بخواهیم نمونه ای را از ProductService ایجاد نماییم، باید به عنوان پارامتر ورودی سازنده، شی ایجاد شده از جنس کلاس ProductRepository موجود در لایه Repository را به آن ارسال نماییم. اما از آنجایی که میخواهیم تفکیک پذیری لایهها از بین نرود و UI بسته به نیاز خود، نمونه مورد نیاز را ایجاد نموده و به این کلاس ارسال کند، از ابزارهایی برای این منظور استفاده میکنیم. یکی از این ابزارها StructureMap میباشد که یک Inversion of Control Container یا به اختصار IoC Container نامیده میشود. با Inversion of Control در مباحث بعدی بیشتر آشنا خواهید شد. StructureMap ابزاری است که در زمان اجرا، پارامترهای ورودی سازندهی کلاسهایی را که از الگوی Dependency Injection استفاده نموده اند و قطعا پارامتر ورودی آنها از جنس یک Interface میباشد را، با ایجاد شی مناسب مقداردهی مینماید.
به منظور استفاده از StructureMap در Visual Studio 2012 باید بر روی پروژه UI خود کلیک راست نموده و گزینهی Manage NuGet Packages را انتخاب نمایید. در پنجره ظاهر شده و از سمت چپ گزینهی Online و سپس در کادر جستجوی سمت راست و بالای پنجره واژهی structuremap را جستجو کنید. توجه داشته باشید که باید به اینترنت متصل باشید تا بتوانید Package مورد نظر را نصب نمایید. پس از پایان عمل جستجو، در کادر میانی structuremap ظاهر میشود که میتوانید با انتخاب آن و فشردن کلید Install آن را بر روی پروژه نصب نمایید.
جهت آشنایی بیشتر با NuGet و نصب آن در سایر نسخههای Visual Studio میتوانید به لینکهای زیر رجوع کنید:
کلاسی با نام BootStrapper را با کد زیر به پروژه UI خود اضافه کنید:
using StructureMap; using StructureMap.Configuration.DSL; using SoCPatterns.Layered.Repository; using SoCPatterns.Layered.Model; namespace SoCPatterns.Layered.WebUI { public class BootStrapper { public static void ConfigureStructureMap() { ObjectFactory.Initialize(x => x.AddRegistry<ProductRegistry>()); } } public class ProductRegistry : Registry { public ProductRegistry() { For<IProductRepository>().Use<ProductRepository>(); } } }
ممکن است یک WinUI ایجاد کرده باشید که در این صورت به جای فضای نام SoCPatterns.Layered.WebUI از SoCPatterns.Layered.WinUI استفاده نمایید.
هدف کلاس BootStrapper این است که تمامی وابستگیها را توسط StructureMap در سیستم Register نماید. زمانی که کدهای کلاینت میخواهند به یک کلاس از طریق StructureMap دسترسی داشته باشند، Structuremap وابستگیهای آن کلاس را تشخیص داده و بصورت خودکار پیاده سازی واقعی (Concrete Implementation) آن کلاس را، براساس همان چیزی که ما برایش تعیین کردیم، به کلاس تزریق مینماید. متد ConfigureStructureMap باید در همان لحظه ای که Application آغاز به کار میکند فراخوانی و اجرا شود. با توجه به نوع UI خود یکی از روالهای زیر را انجام دهید:
در WebUI:
فایل Global.asax را به پروژه اضافه کنید و کد آن را بصورت زیر تغییر دهید:
namespace SoCPatterns.Layered.WebUI { public class Global : System.Web.HttpApplication { protected void Application_Start(object sender, EventArgs e) { BootStrapper.ConfigureStructureMap(); } } }
در WinUI:
در فایل Program.cs کد زیر را اضافه کنید:
namespace SoCPatterns.Layered.WinUI { static class Program { [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); BootStrapper.ConfigureStructureMap(); Application.Run(new Form1()); } } }
سپس برای طراحی رابط کاربری، با توجه به نوع UI خود یکی از روالهای زیر را انجام دهید:
در WebUI:
صفحه Default.aspx را باز نموده و کد زیر را به آن اضافه کنید:
<asp:DropDownList AutoPostBack="true" ID="ddlCustomerType" runat="server"> <asp:ListItem Value="0">Standard</asp:ListItem> <asp:ListItem Value="1">Trade</asp:ListItem> </asp:DropDownList> <asp:Label ID="lblErrorMessage" runat="server" ></asp:Label> <asp:Repeater ID="rptProducts" runat="server" > <HeaderTemplate> <table> <tr> <td>Name</td> <td>RRP</td> <td>Selling Price</td> <td>Discount</td> <td>Savings</td> </tr> <tr> <td colspan="5"><hr /></td> </tr> </HeaderTemplate> <ItemTemplate> <tr> <td><%# Eval("Name") %></td> <td><%# Eval("RRP")%></td> <td><%# Eval("SellingPrice") %></td> <td><%# Eval("Discount") %></td> <td><%# Eval("Savings") %></td> </tr> </ItemTemplate> <FooterTemplate> </table> </FooterTemplate> </asp:Repeater>
در WinUI:
فایل Form1.Designer.cs را باز نموده و کد آن را بصورت زیر تغییر دهید:
#region Windows Form Designer generated code /// <summary> /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> private void InitializeComponent() { this.cmbCustomerType = new System.Windows.Forms.ComboBox(); this.dgvProducts = new System.Windows.Forms.DataGridView(); this.colName = new System.Windows.Forms.DataGridViewTextBoxColumn(); this.colRrp = new System.Windows.Forms.DataGridViewTextBoxColumn(); this.colSellingPrice = new System.Windows.Forms.DataGridViewTextBoxColumn(); this.colDiscount = new System.Windows.Forms.DataGridViewTextBoxColumn(); this.colSavings = new System.Windows.Forms.DataGridViewTextBoxColumn(); ((System.ComponentModel.ISupportInitialize)(this.dgvProducts)).BeginInit(); this.SuspendLayout(); // // cmbCustomerType // this.cmbCustomerType.DropDownStyle = System.Windows.Forms.ComboBoxStyle.DropDownList; this.cmbCustomerType.FormattingEnabled = true; this.cmbCustomerType.Items.AddRange(new object[] { "Standard", "Trade"}); this.cmbCustomerType.Location = new System.Drawing.Point(12, 90); this.cmbCustomerType.Name = "cmbCustomerType"; this.cmbCustomerType.Size = new System.Drawing.Size(121, 21); this.cmbCustomerType.TabIndex = 3; // // dgvProducts // this.dgvProducts.ColumnHeadersHeightSizeMode = System.Windows.Forms.DataGridViewColumnHeadersHeightSizeMode.AutoSize; this.dgvProducts.Columns.AddRange(new System.Windows.Forms.DataGridViewColumn[] { this.colName, this.colRrp, this.colSellingPrice, this.colDiscount, this.colSavings}); this.dgvProducts.Location = new System.Drawing.Point(12, 117); this.dgvProducts.Name = "dgvProducts"; this.dgvProducts.Size = new System.Drawing.Size(561, 206); this.dgvProducts.TabIndex = 2; // // colName // this.colName.DataPropertyName = "Name"; this.colName.HeaderText = "Product Name"; this.colName.Name = "colName"; this.colName.ReadOnly = true; // // colRrp // this.colRrp.DataPropertyName = "Rrp"; this.colRrp.HeaderText = "RRP"; this.colRrp.Name = "colRrp"; this.colRrp.ReadOnly = true; // // colSellingPrice // this.colSellingPrice.DataPropertyName = "SellingPrice"; this.colSellingPrice.HeaderText = "Selling Price"; this.colSellingPrice.Name = "colSellingPrice"; this.colSellingPrice.ReadOnly = true; // // colDiscount // this.colDiscount.DataPropertyName = "Discount"; this.colDiscount.HeaderText = "Discount"; this.colDiscount.Name = "colDiscount"; // // colSavings // this.colSavings.DataPropertyName = "Savings"; this.colSavings.HeaderText = "Savings"; this.colSavings.Name = "colSavings"; this.colSavings.ReadOnly = true; // // Form1 // this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F); this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font; this.ClientSize = new System.Drawing.Size(589, 338); this.Controls.Add(this.cmbCustomerType); this.Controls.Add(this.dgvProducts); this.Name = "Form1"; this.Text = "Form1"; ((System.ComponentModel.ISupportInitialize)(this.dgvProducts)).EndInit(); this.ResumeLayout(false); } #endregion private System.Windows.Forms.ComboBox cmbCustomerType; private System.Windows.Forms.DataGridView dgvProducts; private System.Windows.Forms.DataGridViewTextBoxColumn colName; private System.Windows.Forms.DataGridViewTextBoxColumn colRrp; private System.Windows.Forms.DataGridViewTextBoxColumn colSellingPrice; private System.Windows.Forms.DataGridViewTextBoxColumn colDiscount; private System.Windows.Forms.DataGridViewTextBoxColumn colSavings;
سپس در Code Behind، با توجه به نوع UI خود یکی از روالهای زیر را انجام دهید:
در WebUI:
وارد کد نویسی صفحه Default.aspx شده و کد آن را بصورت زیر تغییر دهید:
using System; using System.Collections.Generic; using SoCPatterns.Layered.Model; using SoCPatterns.Layered.Presentation; using SoCPatterns.Layered.Service; using StructureMap; namespace SoCPatterns.Layered.WebUI { public partial class Default : System.Web.UI.Page, IProductListView { private ProductListPresenter _productListPresenter; protected void Page_Init(object sender, EventArgs e) { _productListPresenter = new ProductListPresenter(this,ObjectFactory.GetInstance<Service.ProductService>()); this.ddlCustomerType.SelectedIndexChanged += delegate { _productListPresenter.Display(); }; } protected void Page_Load(object sender, EventArgs e) { if(!Page.IsPostBack) _productListPresenter.Display(); } public void Display(IList<ProductViewModel> products) { rptProducts.DataSource = products; rptProducts.DataBind(); } public CustomerType CustomerType { get { return (CustomerType) int.Parse(ddlCustomerType.SelectedValue); } } public string ErrorMessage { set { lblErrorMessage.Text = String.Format("<p><strong>Error:</strong><br/>{0}</p>", value); } } } }
در WinUI:
وارد کدنویسی Form1 شوید و کد آن را بصورت زیر تغییر دهید:
using System; using System.Collections.Generic; using System.Windows.Forms; using SoCPatterns.Layered.Model; using SoCPatterns.Layered.Presentation; using SoCPatterns.Layered.Service; using StructureMap; namespace SoCPatterns.Layered.WinUI { public partial class Form1 : Form, IProductListView { private ProductListPresenter _productListPresenter; public Form1() { InitializeComponent(); _productListPresenter = new ProductListPresenter(this, ObjectFactory.GetInstance<Service.ProductService>()); this.cmbCustomerType.SelectedIndexChanged += delegate { _productListPresenter.Display(); }; dgvProducts.AutoGenerateColumns = false; cmbCustomerType.SelectedIndex = 0; } public void Display(IList<ProductViewModel> products) { dgvProducts.DataSource = products; } public CustomerType CustomerType { get { return (CustomerType)cmbCustomerType.SelectedIndex; } } public string ErrorMessage { set { MessageBox.Show( String.Format("Error:{0}{1}", Environment.NewLine, value)); } } } }
با توجه به کد فوق، نمونه ای را از کلاس ProductListPresenter، در لحظهی نمونه سازی اولیهی کلاس UI، ایجاد نمودیم. با استفاده از متد ObjectFactory.GetInstance مربوط به StructureMap، نمونه ای از کلاس ProductService ایجاد شده است و به سازندهی کلاس ProductListPresenter ارسال گردیده است. در مورد Structuremap در مباحث بعدی با جزئیات بیشتری صحبت خواهم کرد. پیاده سازی معماری لایه بندی در اینجا به پایان رسید.
اما اصلا نگران نباشید، شما فقط پرواز کوتاه و مختصری را بر فراز کدهای معماری لایه بندی داشته اید که این فقط یک دید کلی را به شما در مورد این معماری داده است. این معماری هنوز جای زیادی برای کار دارد، اما در حال حاضر شما یک Applicaion با پیوند ضعیف (Loosely Coupled) بین لایهها دارید که دارای قابلیت تست پذیری قوی، نگهداری و پشتیبانی آسان و تفکیک پذیری قدرتمند بین اجزای آن میباشد. شکل زیر تعامل بین لایهها و وظایف هر یک از آنها را نمایش میدهد.
public static bool TryGetNonEnumeratedCount(this IEnumerable<T> source, out int count);
if (movies.TryGetNonEnumeratedCount(out int count)) { Console.WriteLine($"The count is {count}"); } else { Console.WriteLine("Could not get a count of movies without enumerating the collection"); }
الگوی معکوس سازی کنترل چیست؟
IoC یک الگوی سطح بالا است و به روشهای مختلفی به مسایل متفاوتی جهت معکوس سازی کنترل، قابل اعمال میباشد؛ مانند:
- کنترل اینترفیسهای بین دو سیستم
- کنترل جریان کاری برنامه
- کنترل بر روی ایجاد وابستگیها (جایی که تزریق وابستگیها و DI ظاهر میشوند)
سؤال: بین IoC و DIP چه تفاوتی وجود دارد؟
در DIP (قسمت قبل) به این نتیجه رسیدیم که یک ماژول سطح بالاتر نباید به جزئیات پیاده سازیهای ماژولی سطح پایینتر وابسته باشد. هر دوی اینها باید بر اساس Abstraction با یکدیگر ارتباط برقرار کنند. IoC روشی است که این Abstraction را فراهم میکند. در DIP فقط نگران این هستیم که ماژولهای موجود در لایههای مختلف برنامه به یکدیگر وابسته نباشند اما بیان نکردیم که چگونه.
معکوس سازی اینترفیسها
هدف از معکوس سازی اینترفیسها، استفاده صحیح و معنا دار از اینترفیسها میباشد. به این معنا که صرفا تعریف اینترفیسها به این معنا نیست که طراحی صحیحی در برنامه بکار گرفته شده است و در حالت کلی هیچ معنای خاصی ندارد و ارزشی را به برنامه و سیستم شما اضافه نخواهد کرد.
برای مثال یک مسابقه بوکس را درنظر بگیرید. در اینجا Ali یک بوکسور است. مطابق عادت معمول، یک اینترفیس را مخصوص این کلاس ایجاد کرده، به نام IAli و مسابقه بوکس از آن استفاده خواهد کرد. در اینجا تعریف یک اینترفیس برای Ali، هیچ ارزش افزودهای را به همراه ندارد و متاسفانه عادتی است که در بین بسیاری از برنامه نویسها متداول شده است؛ بدون اینکه علت واقعی آنرا بدانند و تسلطی به الگوهای طراحی برنامه نویسی شیءگرا داشته باشند. صرف اینکه به آنها گفته شده است تعریف اینترفیس خوب است، سعی میکنند برای همه چیز اینترفیس تعریف کنند!
تعریف یک اینترفیس تنها زمانی ارزش خواهد داشت که چندین پیاده سازی از آن ارائه شود. در مثال ما پیاده سازیهای مختلفی از اینترفیس IAli بیمفهوم است. همچنین در دنیای واقعی، در یک مسابقه بوکس، چندین و چند شرکت کننده وجود خواهند داشت. آیا باید به ازای هر کدام یک اینترفیس جداگانه تعریف کرد؟ ضمنا ممکن است اینترفیس IAli متدی داشته باشد به نام ضربه، اینترفیس IVahid متد دیگری داشته باشد به نام دفاع.
کاری که در اینجا جهت طراحی صحیح باید صورت گیرد، معکوس سازی اینترفیسها است. به این ترتیب که مسابقه بوکس است که باید اینترفیس مورد نیاز خود را تعریف کند و آن هم تنها یک اینترفیس است به نام IBoxer. اکنون Ali، Vahid و سایرین باید این اینترفیس را جهت شرکت در مسابقه بوکس پیاده سازی کنند. بنابراین دیگر صرف وجود یک کلاس، اینترفیس مجزایی برای آن تعریف نشده و بر اساس معکوس سازی کنترل است که تعریف اینترفیس IBoxer معنا پیدا کرده است. اکنون IBoxer دارای چندین و چند پیاده سازی خواهد بود. به این ترتیب، تعریف اینترفیس، ارزشی را به سیستم افزوده است.
به این نوع معکوس سازی اینترفیسها، الگوی provider model نیز گفته میشود. برای مثال کلاسی که از چندین سرویس استفاده میکند، بهتر است یک IService را ایجاد کرده و تامین کنندههایی، این IService را پیاده سازی کنند. نمونهای از آن در دنیای دات نت، Membership Provider موجود در ASP.NET است که پیاده سازیهای بسیاری از آن تاکنون تهیه و ارائه شدهاند.
معکوس سازی جریان کاری برنامه
جریان کاری معمول یک برنامه یا Noraml flow، عموما رویهای یا Procedural است؛ به این معنا که از یک مرحله به مرحلهای بعد هدایت خواهد شد. برای مثال یک برنامه خط فرمان را درنظر بگیرید که ابتدا میپرسد نام شما چیست؟ در مرحله بعد مثلا رنگ مورد علاقه شما را خواهد پرسید.
برای معکوس سازی این جریان کاری، از یک رابط کاربری گرافیکی یا GUI استفاده میشود. مثلا یک فرم را درنظر بگیرید که در آن دو جعبه متنی، کار دریافت نام و رنگ را به عهده دارند؛ به همراه یک دکمه ثبت اطلاعات. به این ترتیب بجای اینکه برنامه، مرحله به مرحله کاربر را جهت ثبت اطلاعات هدایت کند، کنترل به کاربر منتقل و معکوس شده است.
معکوس سازی تولید اشیاء
معکوس سازی تولید اشیاء، اصل بحث دوره و سری جاری را تشکیل میدهد و در ادامه مباحث، بیشتر و عمیقتر بررسی خواهد گردید.
روش متداول تعریف و استفاده از اشیاء دیگر درون یک کلاس، وهله سازی آنها توسط کلمه کلیدی new است. به این ترتیب از یک وابستگی به صورت مستقیم درون کدهای کلاس استفاده خواهد شد. بنابراین در این حالت کلاسهای سطح بالاتر به ماژولهای سطح پایین، به صورت مستقیم وابسته میگردند.
برای اینکه این کنترل را معکوس کنیم، نیاز است ایجاد و وهله سازی این اشیاء وابستگی را در خارج از کلاس جاری انجام دهیم. شاید در اینجا بپرسید که چرا؟
اگر با الگوی طراحی شیءگرای Factory آشنا باشید، همان ایده در اینجا مدنظر است:
Button button; switch (UserSettings.UserSkinType) { case UserSkinTypes.Normal: button = new Button(); break; case UserSkinTypes.Fancy: button = new FancyButton(); break; }
حال در این برنامه اگر قرار باشد کار و کنترل محل وهله سازی این دکمهها معکوس نشود، در هر قسمتی از برنامه نیاز است این سوئیچ تکرار گردد (برای مثال در چند ده فرم مختلف برنامه). بنابراین بهتر است محل ایجاد این دکمهها به کلاس دیگری منتقل شود مانند ButtonFactory و سپس از این کلاس در مکانهای مختلف برنامه استفاده گردد:
Button button = ButtonFactory.CreateButton();
بنابراین در مثال فوق، کنترل ایجاد دکمهها به یک کلاس پایه قرار گرفته در خارج از کلاس جاری، معکوس شده است.
انواع معکوس سازی تولید اشیاء
بسیاری شاید تصور کنند که تنها راه معکوس سازی تولید اشیاء، تزریق وابستگیها است؛ اما روشهای چندی برای انجام اینکار وجود دارد:
الف) استفاده از الگوی طراحی Factory (که نمونهای از آنرا در قسمت قبل مشاهده کردید)
ب) استفاده از الگوی Service Locator
Button button = ServiceLocator.Create(IButton.Class)
ج) تزریق وابستگیها
Button button = GetTheButton(); Form1 frm = new Form1(button);
به صورت خلاصه هر زمانیکه تولید و وهله سازی وابستگیهای یک کلاس را به خارج از آن منتقل کردید، کار معکوس سازی تولید وابستگیها انجام شده است.
int a = default(int);
var number = default(int); // 0 var date = default(DateTime); // DateTime.MinValue var obj = default(object); // null
int a = default; // 0 Guid guid = default; // 00000000-0000-0000-0000-000000000000
مثالهایی از default Literals در C# 7.1
C# 7.1 | C# 7.0 | |
int i = default; | int i = default(int); | Local Variable Defaults |
Person Create() => default; | Person Create() => default(Person); | Local function |
Person Create(string name, int age = default) | Person Create(string name, int age = default(int)) | Optional Parameter Default Value |
(string Name, int Age) person = ("User 1", default); | (string Name, int Age) person = ("User 1", default(int)); | Tuple Element Default Value |
Person p = new Person { Name = default, Age = default }; | Person p = new Person { Name = default(string), Age = default(int) }; | Object Initializer Default Value |
var people = new[] { new Person(), default, new Person() }; var ages = new[] {18, default, 50}; | var people = new[] { new Person(), default(Person), new Person() }; var ages = new[] {18, default(int), 50}; | Array Initializer Default Value |
int i = default; Console.WriteLine(i is default); | int i = default(int); Console.WriteLine(i is default(int)); // true | Is Operator |
// Local method returning a tuple (T, T) CreateTwo<T>() => (default, default); | // Local method returning a tuple (T, T) CreateTwo<T>() => (default(T), default(T)); | Generic Defaults |
bool IsAnswerKnown()=> false; int? p = IsAnswerKnown() ? 42 : default; | bool IsAnswerKnown()=> false; int? p = IsAnswerKnown() ? 42 : (int?)null; | Conditional Operator Defaults |
در این مثالها مفهوم type inference را بهتر میتوان مشاهده کرد. برای مثال در آرایهی ذیل چون اعضای آن int هست، مقدار default نیز به همان مقدار پیشفرض int اشاره میکند و همچنین نوع آرایه نیز int درنظر گرفته میشود و نیازی به ذکر آن نیست:
var ages = new[] {18, default, 50};
var ages = new[] { default };
نمونهی دیگر آن قطعه کد ذیل است:
string s = default; if(s == default) { }
و یا در مقایسهی ذیل 1.5 یک عدد double است. بنابراین default در اینجا به مقدار پیشفرض double و یا 0.0 اشاره میکند:
int a = default; var x = a > 0 ? default : 1.5;
لغو اعمال غیرهمزمان
مدل لغو اعمال
پایه لغو اعمال، توسط مکانیزمی به نام CancellationToken پیاده سازی شدهاست و آنرا به عنوان یکی از آرگومانهای متدهایی که لغو اعمال را پشتیبانی میکنند، مشاهده خواهید کرد. به این ترتیب یک عمل خاص میتواند دریابد چه زمانی لغو آن درخواست شدهاست. البته باید دقت داشت که این عملیات بر مبنای ایدهی همه یا هیچ است. به این معنا که یک درخواست لغو را بار دیگر نمیتوان لغو کرد.
یک مثال استفاده از CancellationToken
کدهای زیر، یک فایل حجیم را از مکانی به مکانی دیگر کپی میکنند. برای این منظور از متد CopyToAsync که در دات نت 4.5 اضافه شدهاست، استفاده کردهایم؛ زیرا از مکانیزم لغو عملیات پشتیبانی میکند.
using System; using System.IO; using System.Threading; namespace Async08 { class Program { static void Main(string[] args) { var source = @"c:\dir\file.bin"; var target = @"d:\dir\file.bin"; using (var inStream = File.OpenRead(source)) { using (var outStream = File.OpenWrite(target)) { using (var cts = new CancellationTokenSource()) { var task = inStream.CopyToAsync(outStream, bufferSize: 4059, cancellationToken: cts.Token); Console.WriteLine("Press 'c' to cancel."); var key = Console.ReadKey().KeyChar; if (key == 'c') { Console.WriteLine("Cancelling"); cts.Cancel(); } Console.WriteLine("Wating..."); task.ContinueWith(t => { }).Wait(); Console.WriteLine("Status: {0}", task.Status); } } } } } }
علت استفاده از ContinueWith در اینجا این است که اگر یک task لغو شود، فراخوانی متد Wait بر روی آن سبب بروز استثناء میگردد. به همین جهت توسط ContinueWith یک Task خالی ایجاد شده و سپس بر روی آن Wait فراخوانی گردیدهاست.
همچنین باید دقت داشت که سازندهی CancellationTokenSource امکان دریافت زمان timeout عملیات را نیز دارد. به علاوه متد CancelAfter نیز برای آن طراحی شدهاست. نمونهی دیگری از تنظیم timeout را در قسمت قبل با معرفی متد Task.Delay و استفاده از آن با Task.WhenAny مشاهده کردید.
لغو ظاهری وظایفی که لغو پذیر نیستند
فرض کنید متدی به نام GetBitmapAsync با پارامتر cancellationToken طراحی نشدهاست. در این حالت کاربر قصد دارد با کلیک بر روی دکمهی لغو، عملیات را خاتمه دهد. یک روش حل این مساله، استفاده از متد ذیل است:
public static class CancellationTokenExtensions { public static async Task UntilCompletionOrCancellation(Task asyncOp, CancellationToken ct) { var tcs = new TaskCompletionSource<bool>(); using (ct.Register(() => tcs.TrySetResult(true))) { await Task.WhenAny(asyncOp, tcs.Task); } } }
این مورد هر چند task اول را واقعا لغو نمیکند، اما سبب خواهد شد تا کدهای پس از await UntilCompletionOrCancellation اجرا شوند.
طراحی متدهای غیرهمزمان لغو پذیر
کلاس زیر را در نظر بگیرید:
public class CancellationTokenTest { public static void Run() { var cts = new CancellationTokenSource(); Task.Run(async () => await test(), cts.Token); Console.ReadLine(); cts.Cancel(); Console.WriteLine("Cancel..."); Console.ReadLine(); } private static async Task test() { while (true) { await Task.Delay(1000); Console.WriteLine("Test..."); } } }
Test... Test... Test... Cancel... Test... Test... Test... Test...
روش اول حل این مشکل، معرفی پارامتر CancellationToken به متد test و سپس بررسی مداوم خاصیت IsCancellationRequested آن میباشد:
public class CancellationTokenTest { public static void Run() { var cts = new CancellationTokenSource(); Task.Run(async () => await test(cts.Token), cts.Token); Console.ReadLine(); cts.Cancel(); Console.WriteLine("Cancel..."); Console.ReadLine(); } private static async Task test(CancellationToken ct) { while (true) { await Task.Delay(1000, ct); Console.WriteLine("Test..."); if (ct.IsCancellationRequested) { break; } } Console.WriteLine("Test cancelled"); } }
روش دوم لغو عملیات، استفاده از متد Register است. هر زمان که توکن لغو شود، callback آن فراخوانی خواهد شد:
private static async Task test2(CancellationToken ct) { bool isRunning = true; ct.Register(() => { isRunning = false; Console.WriteLine("Query cancelled"); }); while (isRunning) { await Task.Delay(1000, ct); Console.WriteLine("Test..."); } Console.WriteLine("Test cancelled"); }
متدی تحت عنوان ValidateEmail را تصور کنید. این متد از حیث بازگشت نتیجه به عنوان خروجی میتواند به اشکال مختلفی پیاده سازی شود که در ادامه مشاهده میکنیم:
متد ValidateEmail با خروجی Boolean
public bool ValidateEmail(string email) { var valid = true; if (string.IsNullOrWhiteSpace(email)) { valid = false; } var isValidFormat = true;//todo: using RegularExpression if (!isValidFormat) { valid = false; } var isRealDoamin = true;//todo: Code here that confirms whether domain exists. if (!isRealDoamin) { valid = false; } return valid; }
همانطور که در تکه کد زیر مشخص میباشد، استفاده کننده از متد بالا، امکان بررسی خروجی آن را در قالب یک شرط خواهد داشت و علاوه بر اینکه پیاده سازی آن ساده میباشد، خوانایی کد را نیز بالا میبرد؛ ولی با این حال نمیتوان متوجه شد مشکل اصلی آدرس ایمیل ارسالی به عنوان آرگومان، دقیقا چیست.
var email = "email@example.com"; var isValid = ValidateEmail(email); if(isValid) { //do something }
متد ValidateEmail با صدور استثناء
public void ValidateEmail(string email) { if (string.IsNullOrWhiteSpace(email)) throw new ArgumentNullException(nameof(email)); var isValidFormat = true;//todo: using RegularExpression if (!isValidFormat) throw new ArgumentException("email is not in a correct format"); var isRealDoamin = true;//todo: Code here that confirms whether domain exists. if (!isRealDoamin) throw new ArgumentException("email does not include a valid domain.") }
روش بالا هم جواب میدهد ولی بهتر است کلاس Exception سفارشی به عنوان مثال ValidationException برای این قضیه در نظر گرفته شود تا بتوان وهلههای صادر شده از این نوع را در لایههای بالاتر مدیریت کرد.
متد ValidateEmail با چندین خروجی
برای این منظور چندین راه حل پیش رو داریم.
با استفاده از پارامتر out:
public bool ValidateEmail(string email, out string message) { var valid = true; message = string.Empty; if (string.IsNullOrWhiteSpace(email)) { valid = false; message = "email is null."; } if (valid) { var isValidFormat = true;//todo: using RegularExpression if (!isValidFormat) { valid = false; message = "email is not in a correct format"; } } if (valid) { var isRealDoamin = true;//todo: Code here that confirms whether domain exists. if (!isRealDoamin) { valid = false; message = "email does not include a valid domain."; } } return valid; }
var email = "email@example.com"; var isValid = ValidateEmail(email, out string message); if (isValid) { //do something }
Tuple<bool, List<string>> result = Tuple.Create<bool, List<string>>(true, new List<string>());
public class OperationResult { public bool Success { get; set; } public IList<string> Messages { get; } = new List<string>(); public void AddMessage(string message) { Messages.Add(message); } }
public OperationResult ValidateEmail(string email) { var result = new OperationResult(); if (string.IsNullOrWhiteSpace(email)) { result.Success = false; result.AddMessage("email is null."); } if (result.Success) { var isValidFormat = true;//todo: using RegularExpression if (!isValidFormat) { result.Success = false; result.AddMessage("email is not in a correct format"); } } if (result.Success) { var isRealDoamin = true;//todo: Code here that confirms whether domain exists. if (!isRealDoamin) { result.Success = false; result.AddMessage("email does not include a valid domain."); } } return result; }
این بار خروجی متد مذکور از نوع OperationResult ای میباشد که هم موفقیت آمیز بودن یا عدم آن را مشخص میکند و همچنین امکان دسترسی به لیست پیغامهای مرتبط با اعتبارسنجیهای انجام شده، وجود دارد.
استفاده از Exception برای نمایش پیغام برای کاربر نهایی
با صدور یک استثناء و مدیریت سراسری آن در بالاترین (خارجی ترین) لایه و نمایش پیغام مرتبط با آن به کاربر نهایی، میتوان از آن به عنوان ابزاری برای ارسال هر نوع پیغامی به کاربر نهایی استفاده کرد. اگر قوانین تجاری با موفقیت برآورده نشدهاند یا لازم است به هر دلیلی یک پیغام مرتبط با یک اعتبارسنجی تجاری را برای کاربر نمایش دهید، این روش بسیار کارساز میباشد و با یکبار وقت گذاشتن برای توسعه زیرساخت برای این موضوع به عنوان یک Cross Cutting Concern تحت عنوان Exception Management آزادی عمل زیادی در ادامه توسعه سیستم خود خواهید داشت.
به عنوان مثال داشتن یک کلاس Exception سفارشی تحت عنوان UserFriendlyException در این راستا یک الزام میباشد.
[Serializable] public class UserFriendlyException : Exception { public string Details { get; private set; } public int Code { get; set; } public UserFriendlyException() { } public UserFriendlyException(SerializationInfo serializationInfo, StreamingContext context) : base(serializationInfo, context) { } public UserFriendlyException(string message) : base(message) { } public UserFriendlyException(int code, string message) : this(message) { Code = code; } public UserFriendlyException(string message, string details) : this(message) { Details = details; } public UserFriendlyException(int code, string message, string details) : this(message, details) { Code = code; } public UserFriendlyException(string message, Exception innerException) : base(message, innerException) { } public UserFriendlyException(string message, string details, Exception innerException) : this(message, innerException) { Details = details; } }
و همچنین لازم است در بالاترین لایه سیستم خود به عنوان مثال برای یک پروژه ASP.NET MVC یا ASP.NET Core MVC میتوان یک ExceptionFilter سفارشی نیز تهیه کرد که هم به صورت سراسری استثناءهای سفارشی شما را مدیریت کند و همچنین خروجی مناسب Json برای استفاده در سمت کلاینت را نیز مهیا کند. به عنوان مثال برای درخواستهای Ajax ای لازم است در سمت کلاینت نیز پاسخهای رسیده از سمت سرور به صورت سراسری مدیریت شوند و برای سایر درخواستها همان نمایش صفحات خطای پیغام مرتبط با استثناء رخ داده شده کفایت میکند.
یک مدل پیشنهادی برای تهیه خروجی مناسب برای ارسال جزئیات استثنا رخ داده در درخواستهای Ajax ای
[Serializable] public class MvcAjaxResponse : MvcAjaxResponse<object> { public MvcAjaxResponse() { } public MvcAjaxResponse(bool success) : base(success) { } public MvcAjaxResponse(object result) : base(result) { } public MvcAjaxResponse(ErrorInfo error, bool unAuthorizedRequest = false) : base(error, unAuthorizedRequest) { } } [Serializable] public class MvcAjaxResponse<TResult> : MvcAjaxResponseBase { public MvcAjaxResponse(TResult result) { Result = result; Success = true; } public MvcAjaxResponse() { Success = true; } public MvcAjaxResponse(bool success) { Success = success; } public MvcAjaxResponse(ErrorInfo error, bool unAuthorizedRequest = false) { Error = error; UnAuthorizedRequest = unAuthorizedRequest; Success = false; } /// <summary> /// The actual result object of AJAX request. /// It is set if <see cref="MvcAjaxResponseBase.Success" /> is true. /// </summary> public TResult Result { get; set; } } public class MvcAjaxResponseBase { public string TargetUrl { get; set; } public bool Success { get; set; } public ErrorInfo Error { get; set; } public bool UnAuthorizedRequest { get; set; } public bool __mvc { get; } = true; }
[Serializable] public class ErrorInfo { public int Code { get; set; } public string Message { get; set; } public string Detail { get; set; } public Dictionary<string, string> ValidationErrors { get; set; } public ErrorInfo() { } public ErrorInfo(string message) { Message = message; } public ErrorInfo(int code) { Code = code; } public ErrorInfo(int code, string message) : this(message) { Code = code; } public ErrorInfo(string message, string details) : this(message) { Detail = details; } public ErrorInfo(int code, string message, string details) : this(message, details) { Code = code; } }
public async Task CheckIsDeactiveAsync(long id) { if (await _organizationalUnits.AnyAsync(a => a.Id == id && !a.IsActive).ConfigureAwait(false)) throw new UserFriendlyException("واحد سازمانی جاری غیرفعال میباشد."); }
روش نام گذاری متدهایی که امکان بازگشت خروجی Null را دارند
public User GetById(long id);
[Serializable] public class EntityNotFoundException : Exception { public Type EntityType { get; set; } public object Id { get; set; } public EntityNotFoundException() { } public EntityNotFoundException(string message) : base(message) { } public EntityNotFoundException(string message, Exception innerException) : base(message, innerException) { } public EntityNotFoundException(SerializationInfo serializationInfo, StreamingContext context) : base(serializationInfo, context) { } public EntityNotFoundException(Type entityType, object id) : this(entityType, id, null) { } public EntityNotFoundException(Type entityType, object id, Exception innerException) : base($"There is no such an entity. Entity type: {entityType.FullName}, id: {id}", innerException) { EntityType = entityType; Id = id; } }
یک مثال واقعی
public async Task<UserOrganizationalUnitInfo> GetCurrentOrganizationalUnitInfoOrNullAsync(long userId) { return (await _setting.GetSettingValueForUserAsync( UserSettingNames.CurrentOrganizationalUnitInfo, userId).ConfigureAwait(false)) .FromJsonString<UserOrganizationalUnitInfo>(); }