کار با کلیدهای اصلی و خارجی در EF Code first
مثلا رابطه many-to-many نیازی به این تعریف ندارد چون مدیریت جدول واسط بین دو موجودیت مرتبط که حاوی کلیدهای خارجی به این دو جدول است، خودکار میباشد.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } app.UseHttpsRedirection(); app.UseStaticFiles(); JqGridRequest.ParametersNames = new JqGridParametersNames() { PagesCount = "npage" }; app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapControllerRoute( name: "default", pattern: "{controller=JavaScript}/{action=Basics}/{id?}"); endpoints.MapControllerRoute( name: "default2", pattern: "{controller=StarWars}/{action=Characters}"); endpoints.MapRazorPages(); }); }
یعنی تبدیل رشتهی JSON به شیء متناظر با آن و یا حالت عکس آن گویا به صورت صحیح انجام نمیشه احتمالا باید پروژه Lib.AspNetCore.Mvc.JqGrid بر حسب ASP.NET Core 3.0 کامپایل بشه
در اینجاهم یه کامنت در مورد تغییرات JSON serialization/deserialization گذاشتند
Kendo UI MVVM
- «استفاده از Kendo UI templates »
- «اعتبار سنجی ورودیهای کاربر در Kendo UI»
- «فعال سازی عملیات CRUD در Kendo UI Grid» جهت آشنایی با نحوهی تعریف DataSource ایی که میتواند اطلاعات را ثبت، حذف و یا ویرایش کند.
در این مطلب قصد داریم به یک چنین صفحهای برسیم که در آن در ابتدای نمایش، لیست ثبت نامهای موجود، از سرور دریافت و توسط یک Kendo UI template نمایش داده میشود. سپس امکان ویرایش و حذف هر ردیف، وجود خواهد داشت، به همراه امکان افزودن ردیفهای جدید. در این بین مدیریت نمایش لیست ثبت نامها توسط امکانات binding توکار فریم ورک MVVM مخصوص Kendo UI صورت خواهد گرفت. همچنین کلیه اعمال مرتبط با هر ردیف نیز توسط data binding دو طرفه مدیریت خواهد شد.
Kendo UI MVVM
الگوی MVVM یا Model-View-ViewModel که برای اولین بار جهت کاربردهای WPF و Silverlight معرفی شد، برای ساده سازی اتصال تغییرات کنترلهای برنامه به خواص ViewModel یک View کاربرد دارد. برای مثال با تغییر عنصر انتخابی یک DropDownList در یک View، بلافاصله خاصیت متصل به آن که در ViewModel برنامه تعریف شدهاست، مقدار دهی و به روز خواهد شد. هدف نهایی آن نیز جدا سازی منطق کدهای UI، از کدهای جاوا اسکریپتی سمت کاربر است. برای این منظور کتابخانههایی مانند Knockout.js به صورت اختصاصی برای این کار تهیه شدهاند؛ اما Kendo UI نیز جهت یکپارچگی هرچه تمامتر اجزای آن، دارای یک فریم ورک MVVM توکار نیز میباشد. طراحی آن نیز بسیار شبیه به Knockout.js است؛ اما با سازگاری 100 درصد با کل مجموعه.
پیاده سازی الگوی MVVM از 4 قسمت تشکیل میشود:
- Model که بیانگر خواص متناظر با اشیاء رابط کاربری است.
- View همان رابط کاربری است که به کاربر نمایش داده میشود.
- ViewModel واسطی است بین Model و View. کار آن انتقال دادهها و رویدادها از View به مدل است و در حالت binding دوطرفه، عکس آن نیز صحیح میباشد.
- Declarative data binding جهت رهایی برنامه نویسها از نوشتن کدهای هماهنگ سازی اطلاعات المانهای View و خواص ViewModel کاربرد دارد.
در ادامه این اجزا را با پیاده سازی مثالی که در ابتدای بحث مطرح شد، دنبال میکنیم.
تعریف Model و ViewModel
در سمت سرور، مدل ثبت نام برنامه چنین شکلی را دارد:
namespace KendoUI07.Models { public class Registration { public int Id { set; get; } public string UserName { set; get; } public string CourseName { set; get; } public int Credit { set; get; } public string Email { set; get; } public string Tel { set; get; } } }
<script type="text/javascript"> $(function () { var model = kendo.data.Model.define({ id: "Id", fields: { Id: { type: 'number' }, // leave this set to 0 or undefined, so Kendo knows it is new. UserName: { type: 'string' }, CourseName: { type: 'string' }, Credit: { type: 'number' }, Email: { type: 'string' }, Tel: { type: 'string' } } }); }); </script>
<script type="text/javascript"> $(function () { var viewModel = kendo.observable({ accepted: false, course: new model() }); }); </script>
اتصال ViewModel به View برنامه
تعریف فرم ثبت نام را در اینجا ملاحظه میکنید. فیلدهای مختلف آن بر اساس نکات اعتبارسنجی HTML 5 با ویژگیهای خاص آن، مزین شدهاند. جزئیات آنرا در مطلب «اعتبار سنجی ورودیهای کاربر در Kendo UI» پیشتر بررسی کردهایم.
اگر به تعریف هر فیلد دقت کنید، ویژگی data-bind جدیدی را هم ملاحظه خواهید کرد:
<div id="coursesSection" class="k-rtl k-header"> <div class="box-col"> <form id="myForm" data-role="validator" novalidate="novalidate"> <h3>ثبت نام</h3> <ul> <li> <label for="Id">Id</label> <span id="Id" data-bind="text:course.Id"></span> </li> <li> <label for="UserName">نام</label> <input type="text" id="UserName" name="UserName" class="k-textbox" data-bind="value:course.UserName" required /> </li> <li> <label for="CourseName">دوره</label> <input type="text" dir="ltr" id="CourseName" name="CourseName" required data-bind="value:course.CourseName" /> <span class="k-invalid-msg" data-for="CourseName"></span> </li> <li> <label for="Credit">مبلغ پرداختی</label> <input id="Credit" name="Credit" type="number" min="1000" max="6000" required data-max-msg="عددی بین 1000 و 6000" dir="ltr" data-bind="value:course.Credit" class="k-textbox k-input" /> <span class="k-invalid-msg" data-for="Credit"></span> </li> <li> <label for="Email">پست الکترونیک</label> <input type="email" id="Email" dir="ltr" name="Email" data-bind="value:course.Email" required class="k-textbox" /> </li> <li> <label for="Tel">تلفن</label> <input type="tel" id="Tel" name="Tel" dir="ltr" pattern="\d{8}" required class="k-textbox" data-bind="value:course.Tel" data-pattern-msg="8 رقم" /> </li> <li> <input type="checkbox" name="Accept" data-bind="checked:accepted" required /> شرایط دوره را قبول دارم. <span class="k-invalid-msg" data-for="Accept"></span> </li> <li> <button class="k-button" data-bind="enabled: accepted, click: doSave" type="submit"> ارسال </button> <button class="k-button" data-bind="click: resetModel">از نو</button> </li> </ul> <span id="doneMsg"></span> </form> </div>
<script type="text/javascript"> $(function () { var model = kendo.data.Model.define({ // ... }); var viewModel = kendo.observable({ // ... }); kendo.bind($("#coursesSection"), viewModel); }); </script>
<input type="text" id="UserName" name="UserName" class="k-textbox" data-bind="value:course.UserName" required />
بنابراین تا اینجا به صورت خلاصه، مدلی را توسط متد kendo.data.Model.define، معادل مدل سمت سرور خود ایجاد کردیم. سپس وهلهای از این مدل را به صورت یک خاصیت جدید دلخواهی در ViewModel تعریف شده توسط متد kendo.observable در معرض دید View برنامه قرار دادیم. در ادامه اتصال ViewModel و View، با فراخوانی متد kendo.bind انجام شد. اکنون برای دریافت تغییرات کنترلهای برنامه، تنها کافی است ویژگیهای data-bind ایی را به آنها اضافه کنیم.
در ناحیهی تعریف شده توسط متد kendo.bind، کلیه خواص ViewModel در دسترس هستند. برای مثال اگر به تعریف ViewModel دقت کنید، یک خاصیت دیگر به نام accepted با مقدار false نیز در آن تعریف شدهاست (این خاصیت چون صرفا کاربرد UI داشت، در model برنامه قرار نگرفت). از آن برای اتصال checkbox تعریف شده، به button ارسال اطلاعات، استفاده کردهایم:
<input type="checkbox" name="Accept" data-bind="checked:accepted" required /> <button class="k-button" data-bind="enabled: accepted, click: doSave" type="submit"> ارسال </button>
ارسال دادههای تغییر کردهی ViewModel به سرور
تا اینجا 4 جزء اصلی الگوی MVVM که در ابتدای بحث عنوان شد، تکمیل شدهاند. مدل اطلاعات فرم تعریف گردید. ViewModel ایی که این خواص را به المانهای فرم متصل میکند نیز در ادامه اضافه شدهاست. توسط ویژگیهای data-bind کار Declarative data binding انجام میشود.
در ادامه نیاز است تغییرات ViewModel را به سرور، جهت ثبت، به روز رسانی و حذف نهایی منتقل کرد.
<script type="text/javascript"> $(function () { var model = kendo.data.Model.define({ //... }); var dataSource = new kendo.data.DataSource({ type: 'json', transport: { read: { url: "api/registrations", dataType: "json", contentType: 'application/json; charset=utf-8', type: 'GET' }, create: { url: "api/registrations", contentType: 'application/json; charset=utf-8', type: "POST" }, update: { url: function (course) { return "api/registrations/" + course.Id; }, contentType: 'application/json; charset=utf-8', type: "PUT" }, destroy: { url: function (course) { return "api/registrations/" + course.Id; }, contentType: 'application/json; charset=utf-8', type: "DELETE" }, parameterMap: function (data, type) { // Convert to a JSON string. Without this step your content will be form encoded. return JSON.stringify(data); } }, schema: { model: model }, error: function (e) { alert(e.errorThrown); }, change: function (e) { // فراخوانی در زمان دریافت اطلاعات از سرور و یا تغییرات محلی viewModel.set("coursesDataSourceRows", new kendo.data.ObservableArray(this.view())); } }); var viewModel = kendo.observable({ //... }); kendo.bind($("#coursesSection"), viewModel); dataSource.read(); // دریافت لیست موجود از سرور در آغاز کار }); </script>
متصل کردن DataSource به ViewModel
تا اینجا DataSource ایی جهت کار با سرور تعریف شدهاست؛ اما مشخص نیست که اگر رکوردی اضافه شد، چگونه باید اطلاعات خودش را به روز کند. برای این منظور خواهیم داشت:
<script type="text/javascript"> $(function () { $("#coursesSection").kendoValidator({ // ... }); var model = kendo.data.Model.define({ // ... }); var dataSource = new kendo.data.DataSource({ // ... }); var viewModel = kendo.observable({ accepted: false, course: new model(), doSave: function (e) { e.preventDefault(); console.log("this", this.course); var validator = $("#coursesSection").data("kendoValidator"); if (validator.validate()) { if (this.course.Id == 0) { dataSource.add(this.course); } dataSource.sync(); // push to the server this.set("course", new model()); // reset controls } }, resetModel: function (e) { e.preventDefault(); this.set("course", new model()); } }); kendo.bind($("#coursesSection"), viewModel); dataSource.read(); // دریافت لیست موجود از سرور در آغاز کار }); </script>
در متد doSave، ابتدا بررسی میکنیم آیا اعتبارسنجی فرم با موفقیت انجام شدهاست یا خیر. اگر بله، توسط متد add منبع داده، اطلاعات فرم جاری را توسط شیء course که هم اکنون به تمامی فیلدهای آن متصل است، اضافه میکنیم. در اینجا بررسی شدهاست که آیا Id این اطلاعات صفر است یا خیر. از آنجائیکه از همین متد برای به روز رسانی نیز در ادامه استفاده خواهد شد، در حالت به روز رسانی، Id شیء ثبت شده، از طرف سرور دریافت میگردد. بنابراین غیر صفر بودن این Id به معنای عملیات به روز رسانی است و در این حالت نیازی نیست کار بیشتری را انجام داد؛ زیرا شیء متناظر با آن پیشتر به منبع داده اضافه شدهاست.
استفاده از متد add صرفا به معنای مطلع کردن منبع داده محلی از وجود رکوردی جدید است. برای ارسال این تغییرات به سرور، از متد sync آن میتوان استفاده کرد. متد sync بر اساس متد add یک درخواست POST، بر اساس شیءایی که Id غیر صفر دارد، یک درخواست PUT و با فراخوانی متد remove بر روی منبع داده، یک درخواست DELETE را به سمت سرور ارسال میکند.
متد دلخواه resetModel سبب مقدار دهی مجدد شیء course با یک وهلهی جدید از شیء model میشود. همینقدر برای پاک کردن تمامی کنترلهای صفحه کافی است.
تا اینجا دو متد جدید را در ViewModel برنامه تعریف کردهایم. در مورد نحوهی اتصال آنها به View، به کدهای دو دکمهی موجود در فرم دقت کنید:
<button class="k-button" data-bind="enabled: accepted, click: doSave" type="submit"> ارسال </button> <button class="k-button" data-bind="click: resetModel">از نو</button>
مدیریت سمت سرور ثبت، ویرایش و حذف اطلاعات
در حالت ثبت، متد Post توسط آدرس مشخص شده در قسمت create منبع داده، فراخوانی میگردد. نکتهی مهمی که در اینجا باید به آن دقت داشت، نحوهی بازگشت Id رکورد جدید ثبت شدهاست. اگر این تنظیم صورت نگیرد، Id رکورد جدید را در لیست، مساوی صفر مشاهده خواهید کرد و منبع داده این رکورد را همواره به عنوان یک رکورد جدید، مجددا به سرور ارسال میکند.
using System.Collections.Generic; using System.Linq; using System.Net; using System.Net.Http; using System.Web.Http; using KendoUI07.Models; namespace KendoUI07.Controllers { public class RegistrationsController : ApiController { public HttpResponseMessage Delete(int id) { var item = RegistrationsDataSource.LatestRegistrations.FirstOrDefault(x => x.Id == id); if (item == null) return Request.CreateResponse(HttpStatusCode.NotFound); RegistrationsDataSource.LatestRegistrations.Remove(item); return Request.CreateResponse(HttpStatusCode.OK, item); } public IEnumerable<Registration> Get() { return RegistrationsDataSource.LatestRegistrations; } public HttpResponseMessage Post(Registration registration) { if (!ModelState.IsValid) return Request.CreateResponse(HttpStatusCode.BadRequest); var id = 1; var lastItem = RegistrationsDataSource.LatestRegistrations.LastOrDefault(); if (lastItem != null) { id = lastItem.Id + 1; } registration.Id = id; RegistrationsDataSource.LatestRegistrations.Add(registration); // ارسال آی دی مهم است تا از ارسال رکوردهای تکراری جلوگیری شود return Request.CreateResponse(HttpStatusCode.Created, registration); } [HttpPut] // Add it to fix this error: The requested resource does not support http method 'PUT' public HttpResponseMessage Update(int id, Registration registration) { var item = RegistrationsDataSource.LatestRegistrations .Select( (prod, index) => new { Item = prod, Index = index }) .FirstOrDefault(x => x.Item.Id == id); if (item == null) return Request.CreateResponse(HttpStatusCode.NotFound); if (!ModelState.IsValid || id != registration.Id) return Request.CreateResponse(HttpStatusCode.BadRequest); RegistrationsDataSource.LatestRegistrations[item.Index] = registration; return Request.CreateResponse(HttpStatusCode.OK); } } }
نمایش آنی اطلاعات ثبت شده در یک لیست
ردیفهای اضافه شده به منبع داده را میتوان بلافاصله در همان سمت کلاینت توسط Kendo UI Template که قابلیت کار با ViewModelها را دارد، نمایش داد:
<div id="coursesSection" class="k-rtl k-header"> <div class="box-col"> <form id="myForm" data-role="validator" novalidate="novalidate"> <!--فرم بحث شده در ابتدای مطلب--> </form> </div> <div id="results"> <table class="metrotable"> <thead> <tr> <th>Id</th> <th>نام</th> <th>دوره</th> <th>هزینه</th> <th>ایمیل</th> <th>تلفن</th> <th></th> <th></th> </tr> </thead> <tbody data-template="row-template" data-bind="source: coursesDataSourceRows"></tbody> <tfoot data-template="footer-template" data-bind="source: this"></tfoot> </table> <script id="row-template" type="text/x-kendo-template"> <tr> <td data-bind="text: Id"></td> <td data-bind="text: UserName"></td> <td dir="ltr" data-bind="text: CourseName"></td> <td> #: kendo.toString(get("Credit"), "c0") # </td> <td data-bind="text: Email"></td> <td data-bind="text: Tel"></td> <td><button class="k-button" data-bind="click: deleteCourse">حذف</button></td> <td><button class="k-button" data-bind="click: editCourse">ویرایش</button></td> </tr> </script> <script id="footer-template" type="text/x-kendo-template"> <tr> <td colspan="3"></td> <td> جمع کل: #: kendo.toString(totalPrice(), "c0") # </td> <td colspan="2"></td> <td></td> <td></td> </tr> </script> </div> </div>
<script type="text/javascript"> $(function () { // ... var viewModel = kendo.observable({ accepted: false, course: new model(), coursesDataSourceRows: new kendo.data.ObservableArray([]), doSave: function (e) { // ... }, resetModel: function (e) { // ... }, totalPrice: function () { var sum = 0; $.each(this.get("coursesDataSourceRows"), function (index, item) { sum += item.Credit; }); return sum; }, deleteCourse: function (e) { // the current data item is passed as the "data" field of the event argument var course = e.data; dataSource.remove(course); dataSource.sync(); // push to the server }, editCourse: function(e) { // the current data item is passed as the "data" field of the event argument var course = e.data; this.set("course", course); } }); kendo.bind($("#coursesSection"), viewModel); dataSource.read(); // دریافت لیست موجود از سرور در آغاز کار }); </script>
- ابتدا خاصیت دلخواه coursesDataSourceRows به viewModel اضافه میشود تا در ناحیهی coursesSection در دسترس قرار گیرد.
- سپس اگر به انتهای تعریف DataSource دقت کنید، داریم:
<script type="text/javascript"> $(function () { var dataSource = new kendo.data.DataSource({ //... change: function (e) { // فراخوانی در زمان دریافت اطلاعات از سرور و یا تغییرات محلی viewModel.set("coursesDataSourceRows", new kendo.data.ObservableArray(this.view())); } }); }); </script>
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید:
KendoUI07.zip
{ "compilerOptions": { "strict": true, "removeComments": false, "sourceMap": false, "noEmitOnError": true, "target": "ES2020", "module": "ES2020", "outDir": "wwwroot/scripts" }, "include": [ "Scripts/**/*.ts" ], "exclude": [ "node_modules" ] }
<Project Sdk="Microsoft.NET.Sdk.Razor"> <ItemGroup> <PackageReference Include="Microsoft.TypeScript.MSBuild" Version="4.3.5"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> </ItemGroup> <ItemGroup> <Content Remove="tsconfig.json" /> </ItemGroup> <ItemGroup> <TypeScriptCompile Include="tsconfig.json"> <CopyToOutputDirectory>Never</CopyToOutputDirectory> </TypeScriptCompile> </ItemGroup> </Project>
window.exampleJsFunctions = { showPrompt: function (message) { return prompt(message, 'Type anything here'); } };
namespace JSInteropWithTypeScript { export class ExampleJsFunctions { public showPrompt(message: string): string { return prompt(message, 'Type anything here'); } } } export function showPrompt(message: string): string { var fns = new JSInteropWithTypeScript. ExampleJsFunctions(); return fns.showPrompt(message); }
private const string ScriptPath = "./_content/----namespace-here---/scripts/file.js"; private IJSObjectReference scriptModule;
protected override async Task OnAfterRenderAsync(bool firstRender) { if (scriptModule == null) scriptModule = await JSRuntime.InvokeAsync<IJSObjectReference>("import", ScriptPath);
await scriptModule.InvokeVoidAsync("exported fn name", params);
public partial class MyComponent : IAsyncDisposable
public async ValueTask DisposeAsync() { if (scriptModule != null) { await scriptModule.DisposeAsync(); } }
نرمال سازی (قسمت دوم: Second Normal Form)
شما لازمه که یک قید منحصربفرد تکریبی در کنار PK برای آن دو ستون در جدول ایجاد کنید. تا به ازای یک ترم معین و یک دانشجو معین تنها یک معدل ثبت بشه.
پس با لحاظ توضیحات فوق جدول به این شکل در میآید:
create table Avgs ( identifier int not null identity(1,1) primary key, student_id varchar(10) not null references Students term_id tinyint not null references Terms average tinyiny, check (averge between 0 and 20), unique (student_id, term_id) )
ستونی به نام identity وظیفه PK را به عهده میگیره. و از نوع identity هم هست.
دو ستون کد دانشجو و کد معدل کلیدهای خارجی هستند. و ترکیب این دو ستون برای حفظ یکپارچگی و جامعیت دادهها منحصربفرد نظر گرفته شدن.
یک قید هم برای معدل گذاشته شده که معدل غیر متعارف در آن درج نشه.
به سناریوی زیر توجه کنید:
فرض کنید میخواهید بر اساس کد دانشجو و یک ترم معین در جدول برای بدست آوردم معدل جستجو داشته باشید. خب لازمه که بر اساس آن دو ستون جستجو داشته باشید نه آن ستونی که به عنوان PK در نظر گرفته شده. پس محتویات ستون identity کاملا مصنوعی و غیر طبیعی بوده و بطور مستقیم قابل استفاده نیست.
البته لازم به ذکر که عموما کلید اولیه همزمان unique clustered index نیز در نظر گرفته میشه. اگر دادههای این ستون بطور متوالی و پشت سر هم در جدول درج نشن باعث ایجاد fragmentation میشه. و لازمه که ایندکس rebuild بشه.
و اگر کلید اولیه ترکیبی باشه کار در ارتباطات کمی دشوار میشه چون نیاز به کلیدهای خارجی ترکیبی نیز هست.
در joinها نیز چون پیوند بر اساس کلید اولیه و کلیدخارجی هست، هر چه کلید اولیه سبکتر باشه (حچم کمتری داشته باشه و از نوعی باشه که سریعتر توسط پردازنده پردازش بشه) سرعت پردازش نیز طبیعتا افزایش پیدا میکنه.
معرفی برخی عملگرها
در مقالات قبلی مقدماتی را جهت ورود به برنامه نویسی شیء گرا در جاوا اسکریپت مطرح کردیم و در اینجا نیز به معرفی برخی عملگرها میپردازیم که در برنامه نویسی شیء گرا نقشی اساسی را ایفا میکنند.
عملگر typeof
از آنجائیکه جاوا اسکریپت دارای نوع دادهای ضعیف یا Loosely Typed میباشد، باید در بکارگیری متغیرها و یا آرگومانهای ورودی توابع، دقت لازم را داشته باشیم تا خطایی در اجرای کد یا محاسبات به وجود نیاید. بنابراین به راهکارهایی نیاز داریم تا بتوانیم نوع دادهای یک متغیر را تشخیص دهیم و قبل از بکارگیری آنها صحت و اعتبار دادههای ورودی را بررسی کنیم. با استفاده از عملگر typeof میتوانیم نوع دادهای یک متغیر را تشخیص دهیم که برای هر نوع دادهای مقادیر زیر را بر میگرداند:
· برای متغیرهایی که شامل مقدار undefined میباشند مقدار "undefined"
· برای متغیرهای منطقی یا Boolean مقدار "boolean"
· برای متغیرهای رشتهای یا String مقدار "string"
· برای متغیرهای عددی و مقادیر NaN و Infinity مقدار "number"
· برای تابع مقدار "function"
· برای اشیا و مقادیر null مقدار "object"
var x; var n = 12; var obj = {}; var fn = function () { }; var a = new Array(); alert(typeof x); // "undefined" alert(typeof n); // "number" alert(typeof obj); // "object" alert(typeof fn); // "function" alert(typeof a); // "object"
عملگر instanceof
عملگر typeof بهترین روش جهت تشخیص نوع دادهای متغیرهایی است که دارای نوع دادهای پایه یا Primitive Type هستند. اما جهت تشخیص نوع دادهای اشیاء و به صورت کلی انواع ارجاعی، این عملگر فقط مقدار "object" را برمیگرداند و اشارهای به ماهیت واقعی آن Object ندارد. برای این منظور میتوانیم از عملگر instanceof استفاده نماییم تا بررسی کنیم یک نوع ارجاعی از جنس چه نوع Object ی میباشد. شکل کلی استفاده از این عملگر به صورت زیر است:
result = variable instanceof constructor
اگر variable ، از جنس نوع ارجاعی تعیین شده در بخش سازنده یا constructor باشد، عملگر instanceof مقدار true را بر میگرداند. به مثال زیر توجه کنید:
var a = new Array(); alert(a instanceof Array); // true alert(a instanceof Object); // true alert(a instanceof Date); // false
عملگر in
همانطور که قبلا اشاره شد، جهت دسترسی به اعضای یک شیء، میتوان با آن شیء همانند یک آرایه رفتار نمود. به عبارتی دیگر میتوان نام یک ویژگی یا تابع را در [] قرار داد تا به مقدار آن دسترسی داشت. بنابراین میتوان همانند یک آرایه و با استفاده از یک حلقهی for-in تمامی اعضای یک شیء را پیمایش نمود. در واقع عملگر in در این حلقه بررسی میکند چه ویژگیها و توابعی در یک شیء وجود دارند و تمامی آنها را بر میگرداند. به مثال زیر توجه کنید:
var person = { name: "Meysam", age: 33, sayInfo: function () { alert(name + ":" + age); } }; for (var i in person) alert(i + " => " + person[i]);
خروجی :
name => Meysam age => 33 sayInfo => function() { alert(name + ":" + age); }
کاربرد دیگر عملگر in بررسی وجود یک ویژگی یا تابع در یک شیء میباشد. اگر ویژگی یا تابع مورد نظر در شیء وجود داشته باشد، مقدار true را بر میگرداند. به مثال زیر توجه کنید:
alert("name" in person); // true alert("sayInfo" in person); // true alert("birth" in person); // false
عملگر delete
از عملگر delete جهت حذف یک ویژگی و یا یک تابع از یک شیء استفاده میشود. به مثال زیر توجه کنید:
var person = { name: "Meysam", age: 33, sayInfo: function () { alert(name + ":" + age); } }; alert("sayInfo" in person); // true delete person.sayInfo; alert("sayInfo" in person); // false
ویژگی constructor
پس از عملگرهای فوق، یکی از پرکاربردترین ویژگیهایی که برای اشیاء وجود دارد، ویژگی constructor میباشد. در واقع این ویژگی نیز یکی از راهکارهای بررسی صحت و اعتبار متغیرها، آرگومانها و اشیا میباشد. ویژگی constructor ، به تابع سازندهی یک شیء اشاره میکند و آن سازنده را به عنوان خروجی بر میگرداند. دقت داشته باشید که خروجی این ویژگی، خود تابع سازنده میباشد و یک مقدار رشتهای نیست. به مثال زیر توجه کنید:
var obj = {}; var a = new Array(); var x = 10; alert(obj.constructor); alert(obj.constructor === Object); alert(typeof obj.constructor); alert(a.constructor); alert(x.constructor);
خروجی :
function Object() { [native code] } true function function Array() { [native code] } function Number() { [native code] }
در اینجا دیگر آمادهی ورود به برنامه نویسی شیء گرا در جاوا اسکریپت میباشیم که در مقالات بعدی به آن خواهیم پرداخت و همچنین با جزئیات بیشتری اشیاء را تشریح مینماییم.
داشتن یک کتابخانهی مدیریت حالت برای برنامههای React بسیار مفید است؛ خصوصا اگر این برنامه پیچیده باشد و برای مثال در آن نیاز به اشتراک گذاری دادهها، بین دو کامپوننت یا بیشتر که در یک رده سلسه مراتبی قرار نمیگیرند، وجود داشته باشد. اما حتی اگر از یک کتابخانهی مدیریت حالت استفاده شود، شاید راه حلی را که ارائه میکند آنچنان تمیز و قابل انتظار نباشد. با MobX میتوان از ساختارهای پیچیدهی شیءگرا به سادگی استفاده کرد (mutation مستقیم اشیاء در آن مجاز است) و همچنین برای کار با آن به همراه React، نیاز به کدهای کمتری است نسبت به Redux. در اینجا از مفاهیم Reactive programming استفاده میشود؛ اما سعی میکند پیچیدگیهای آنرا مخفی کند. در نام MobX، حرف X به Reactive بودن آن اشاره میکند (مانند RxJS) و ob آن از observable گرفته شدهاست. M هم به حرف ابتدای نام شرکتی اشاره میکند که این کتابخانه را ایجاد کردهاست.
خواص محاسبه شده در جاوا اسکریپت
برای کار با MobX، نیاز است تا ابتدا با یکسری از مفاهیم آن آشنا شد؛ مانند خواص محاسبه شده (computed properties). برای مثال در اینجا یک کلاس متداول جاوا اسکریپتی را داریم:
class Person { constructor(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } fullName() { return `${this.firstName} ${this.lastName}`; } }
const person = new Person('Vahid', 'N'); person.firstName; // 'Vahid' person.lastName; // 'N' person.fullName; // function fullName() {…}
در ES6 برای اینکه تنها با ذکر person.fullName بدون هیچ پرانتزی در مقابل آن بتوان به مقدار کامل fullName رسید، میتوان از روش زیر و با ذکر واژهی کلیدی get، در پیش از نام متد، استفاده کرد:
class Person { constructor(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } get fullName() { return `${this.firstName} ${this.lastName}`; } }
اگر شبیه به همین قطعه کد را بخواهیم در ES5 پیاده سازی کنیم، روش آن به صورت زیر است:
function Person(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } Object.defineProperty(Person.prototype, 'fullName', { get: function () { return this.firstName + ' ' + this.lastName; } });
اکنون فرض کنید قسمتی از state برنامهی React، قرار است خاصیت ویژهی fullName را نمایش دهد. برای اینکه UI برنامه با تغییرات نام و نام خانوادگی، متوجه تغییرات fullName که یک خاصیت محاسباتی است، شود و آنرا رندر مجدد کند، باید در طی یک حلقهی بینهایت، مدام آنرا فراخوانی کند و نتیجهی جدید را با نتیجهی قبلی محاسبه کرده و تغییرات را نمایش دهد. اینجا است که MobX یک چنین پیاده سازیهایی را به کمک مفهوم decorators، ساده میکند.
Decorators در جاوا اسکریپت
تزئین کنندهها یا decorators در سایر زبانهای برنامه نویسی نیز وجود دارند؛ اما پیاده سازی آنها در جاوا اسکریپت هنوز در مرحلهی آزمایشی است. Decorators در جاوا اسکریپت چیزی نیستند بجز بیان زیبای higher-order functions.
higher-order functions، توابعی هستند که توابع دیگر را با ارائهی قابلیتهای بیشتری، محصور میکنند. به همین جهت هر کاری را که بتوان با تزئین کنندهها انجام داد، همان را با توابع معمولی جاوا اسکریپتی نیز میتوان انجام داد. یک نمونه از این higher-order functions را در سری جاری تحت عنوان higher-order components با متد connect کتابخانهی react-redux مشاهده کردهایم. متد connect، متدی است که متدهای نگاشت state به props و نگاشت dispatch به props را دریافت کرده و سپس یک کامپوننت را نیز دریافت میکند و آنرا به صورت محصور شدهای ارائه میدهد تا بجای کامپوننت اصلی مورد استفاده قرار گیرد؛ به یک چنین کامپوننتهایی، higher-order components گفته میشود.
برای تعریف تزئین کنندهها، به نحوهی پیاده سازی Object.defineProperty در مثال فوق دقت کنید:
Object.defineProperty(Person.prototype, 'fullName', { enumerable: false, writable: false, get: function () { return this.firstName + ' ' + this.lastName; } });
در ذیل روش تعریف یک تزئین کننده را مشاهده میکنید که دقیقا از یک چنین الگویی پیروی میکند:
function decoratorName(target, key, descriptor) { // … }
function readonly(target, key, descriptor) { descriptor.writable = false; return descriptor; }
class Person { constructor(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } @readonly get fullName() { return `${this.firstName} ${this.lastName}`; } }
مثالهایی از تزئین کنندهها
برای نمونه میتوان تزئین کنندهی bindThis@ را طراحی کرد تا کار bind شیء this را به متدهای کامپوننتهای React انجام دهد و یا کتابخانهای به نام core-decorators وجود دارد که به صورت زیر نصب میشود:
> npm install core-decorators
@autobind @deprecate @readonly @memoize @debounce @profile
نمونهی دیگری از این کتابخانهها lodash-decorators است که تعدادی دیگر از تزئین کنندهها را ارائه میکند.
MobX چگونه کار میکند؟
انجام یکسری از کارها با Redux مشکل است؛ برای مثال تغییر دادن یک شیء تو در توی پیچیده که شامل تهیهی یک کپی از آن، اعمال تغییرات و غیرهاست. اما با MobX میتوان با اشیاء جاوا اسکریپتی به همان صورتی که هستند کار کرد. برای مثال آرایهای را با متدهای push و pop تغییر داد (mutation اشیاء مجاز است) و یا خواص اشیاء را به صورت مستقیم ویرایش کرد، در این حالت MobX اعلام میکند که ... من میدانم که چه تغییری صورت گرفتهاست. بنابراین سبب رندر مجدد UI خواهم شد.
ایجاد یک برنامهی خالی React برای آزمایش MobX
در اینجا برای بررسی MobX، یک پروژهی جدید React را ایجاد میکنیم:
> create-react-app state-management-with-mobx-part1 > cd state-management-with-mobx-part1 > npm start
> npm install --save mobx
مثالی از MobX، مستقل از React
در اینجا نیز همانند روشی که در بررسی Redux در پیش گرفتیم، ابتدا MobX را به صورت کاملا مستقل از React، با یک مثال بررسی میکنیم و سپس در قسمتهای بعد آنرا به React متصل میکنیم. برای این منظور ابتدا فایل src\index.js را به صورت زیر تغییر میدهیم:
import { autorun, observable } from "mobx"; import React from "react"; import ReactDOM from "react-dom"; ReactDOM.render( <div> <input type="text" id="text-input" /> <div id="text-display"></div> <div id="text-display-uppercase"></div> </div>, document.getElementById("root") ); const input = document.getElementById("text-input"); const textDisplay = document.getElementById("text-display"); const loudDisplay = document.getElementById("text-display-uppercase"); console.log({ observable, autorun, input, textDisplay, loudDisplay });
- با استفاده از observable میخواهیم تغییرات یک شیء جاوا اسکریپتی را تحت نظر قرار داده و هر زمانیکه تغییری در شیء رخ داد، از آن مطلع شویم.
برای مثال شیء سادهی جاوا اسکریپتی زیر را در نظر بگیرید:
{ value: "Hello world!", get uppercase() { return this.value.toUpperCase(); } }
به همین جهت اینبار شیء فوق را توسط یک observable ارائه میدهیم، تا بتوانیم به تغییرات خواص آن گوش فرا دهیم:
const text = observable({ value: "Hello world!", get uppercase() { return this.value.toUpperCase(); } });
input.addEventListener("keyup", event => { text.value = event.target.value; });
autorun(() => { textDisplay.textContent = text.value; loudDisplay.textContent = text.uppercase; });
برای آزمایش آن، برنامه را اجرا کرده و متنی را داخل textbox وارد کنید:
نکتهی جالب اینجا است که هرچند فقط خاصیت value را تغییر دادهایم (تغییر مستقیم خواص یک شیء؛ بدون نیاز به ساخت یک clone از آن)، اما خاصیت محاسباتی uppercase نیز به روز رسانی شدهاست.
زمانیکه mobx را به یک برنامهی React متصل میکنیم، قسمت autorun، از دید ما مخفی خواهد بود. در این حالت فقط یک شیء معمولی جاوا اسکریپتی را مستقیما تغییر میدهیم و ... در نتیجهی آن رندر مجدد UI صورت خواهد گرفت.
یک observable چگونه کار میکند؟
در اینجا یک شبهکد را که بیانگر نحوهی عملکرد یک observable است، مشاهده میکنید:
const onChange = (oldValue, newValue) => { // Tell MobX that this value has changed. } const observable = (value) => { return { get() { return value; }, set(newValue) { onChange(this.get(), newValue); value = newValue; } } }
کدهای کامل این قسمت را میتوانید از اینجا دریافت کنید: state-management-with-mobx-part1.zip
EF Code First #11
استفاده از الگوی Repository اضافی در EF Code first؛ آری یا خیر؟!
اگر در ویژوال استودیو، اشارهگر ماوس را بر روی تعریف DbContext قرار دهیم، راهنمای زیر ظاهر میشود:
A DbContext instance represents a combination of the Unit Of Work and Repository patterns such that
it can be used to query from a database and group together changes that will then be written back to
the store as a unit. DbContext is conceptually similar to ObjectContext.
در اینجا تیم EF صراحتا عنوان میکند که DbContext در EF Code first همان الگوی Unit Of Work را پیاده سازی کرده و در داخل کلاس مشتق شده از آن، DbSetها همان Repositories هستند (فقط نامها تغییر کردهاند؛ اصول یکی است).
به عبارت دیگر با نام بردن صریح از این الگوها، مقصود زیر را دنبال میکنند:
لطفا بر روی این لایه Abstraction ایی که ما تهیه دیدهایم، یک لایه Abstraction دیگر را ایجاد نکنید!
«لایه Abstraction دیگر» یعنی پیاده سازی الگوهای Unit Of Work و Repository جدید، برفراز الگوهای Unit Of Work و Repository توکار موجود!
کار اضافهای که در بسیاری از سایتها مشاهده میشود و ... متاسفانه اکثر آنها هم اشتباه هستند! در ذیل روشهای تشخیص پیاده سازیهای نادرست الگوی Repository را بر خواهیم شمرد:
1) قرار دادن متد Save تغییرات نهایی انجام شده، در داخل کلاس Repository
متد Save باید داخل کلاس Unit of work تعریف شود نه داخل کلاس Repository. دقیقا همان کاری که در EF Code first به درستی انجام شده. متد SaveChanges توسط DbContext ارائه میشود. علت هم این است که در زمان Save ممکن است با چندین Entity و چندین جدول مشغول به کار باشیم. حاصل یک تراکنش، باید نهایتا ذخیره شود نه اینکه هر کدام از اینها، تراکنش خاص خودشان را داشته باشند.
2) نداشتن درکی از الگوی Unit of work
به Unit of work به شکل یک تراکنش نگاه کنید. در داخل آن با انواع و اقسام موجودیتها از کلاسها و جداول مختلف کار شده و حاصل عملیات، به بانک اطلاعاتی اعمال میگردد. پیاده سازیهای اشتباه الگوی Repository، تمام امکانات را در داخل همان کلاس Repository قرار میدهند؛ که اشتباه است. این نوع کلاسها فقط برای کار با یک Entity بهینه شدهاند؛ در حالیکه در دنیای واقعی، اطلاعات ممکن است از دو Entity مختلف دریافت و نتیجه محاسبات مفروضی به Entity سوم اعمال شود. تمام این عملیات یک تراکنش را تشکیل میدهد، نه اینکه هر کدام، تراکنش مجزای خود را داشته باشند.
3) وهله سازی از DbContext به صورت مستقیم داخل کلاس Repository
4) Dispose اشیاء DbContext داخل کلاس Repository
هر بار وهله سازی DbContext مساوی است با باز شدن یک اتصال به بانک اطلاعاتی و همچنین از آنجائیکه راهنمای ذکر شده فوق را در مورد DbContext مطالعه نکردهاند، زمانیکه در یک متد با سه وهله از سه Repository موجودیتهای مختلف کار میکنید، سه تراکنش و سه اتصال مختلف به بانک اطلاعاتی گشوده شده است. این مورد ذاتا اشتباه است و سربار بالایی را نیز به همراه دارد.
ضمن اینکه بستن DbContext در یک Repository، امکان اعمال کوئریهای بعدی LINQ را غیرممکن میکند. به ظاهر یک شیء IQueryable در اختیار داریم که میتوان بر روی آن انواع و اقسام کوئریهای LINQ را تعریف کرد اما ... در اینجا با LINQ to Objects که بر روی اطلاعات موجود در حافظه کار میکند سر و کار نداریم. اتصال به بانک اطلاعاتی با بستن DbContext قطع شده، بنابراین کوئری LINQ بعدی شما کار نخواهد کرد.
همچنین در EF نمیتوان یک Entity را از یک Context به Context دیگری ارسال کرد. در پیاده سازی صحیح الگوی Repository (دقیقا همان چیزی که در EF Code first به صورت توکار وجود دارد)، Context باید بین Repositories که در اینجا فقط نامش DbSet تعریف شده، به اشتراک گذاشته شود. علت هم این است که EF از Context برای ردیابی تغییرات انجام شده بر روی موجودیتها استفاده میکند (همان سطح اول کش که در قسمتهای قبل به آن اشاره شد). اگر به ازای هر Repository یکبار وهله سازی DbContext انجام شود، هر کدام کش جداگانه خاص خود را خواهند داشت.
5) عدم امکان استفاده از تنها یک DbConetext به ازای یک Http Request
هنگامیکه وهله سازی DbContext به داخل یک Repository منتقل میشود و الگوی واحد کار رعایت نمیگردد، امکان به اشتراک گذاری آن بین Repositoryهای تعریف شده وجود نخواهد داشت. این مساله در برنامههای وب سبب کاهش کارآیی میگردد (باز و بسته شدن بیش از حد اتصال به بانک اطلاعاتی در حالیکه میشد تمام این عملیات را با یک DbContext انجام داد).
نمونهای از این پیاده سازی اشتباه را در اینجا میتوانید پیدا کنید. متاسفانه شبیه به همین پیاده سازی، در پروژه MVC Scaffolding نیز بکارگرفته شده است.
چرا تعریف لایه دیگری بر روی لایه Abstraction موجود در EF Code first اشتباه است؟
یکی از دلایلی که حین تعریف الگوی Repository دوم بر روی لایه موجود عنوان میشود، این است:
«به این ترتیب به سادگی میتوان ORM مورد استفاده را تغییر داد» چون پیاده سازی استفاده از ORM، در پشت این لایه مخفی شده و ما هر زمان که بخواهیم به ORM دیگری کوچ کنیم، فقط کافی است این لایه را تغییر دهیم و نه کل برنامه را.
ولی سؤال این است که هرچند این مساله از هزار فرسنگ بالاتر درست است، اما واقعا تابحال دیدهاید که پروژهای را با یک ORM شروع کنند و بعد سوئیچ کنند به ORM دیگری؟!
ضمنا برای اینکه واقعا لایه اضافی پیاده سازی شده انتقال پذیر باشد، شما باید کاملا دست و پای ORM موجود را بریده و تواناییهای در دسترس آن را به سطح نازلی کاهش دهید تا پیاده سازی شما قابل انتقال باشد. برای مثال یک سری از قابلیتهای پیشرفته و بسیار جالب در NH هست که در EF نیست و برعکس. آیا واقعا میتوان به همین سادگی ORM مورد استفاده را تغییر داد؟ فقط در یک حالت این امر میسر است: از قابلیتهای پیشرفته ابزار موجود استفاده نکنیم و از آن در سطحی بسیار ساده و ابتدایی کمک بگیریم تا از قابلیتهای مشترک بین ORMهای موجود استفاده شود.
ضمن اینکه مباحث نگاشت کلاسها به جداول را چکار خواهید کرد؟ EF راه و روش خاص خودش را دارد، NH چندین و چند روش خاص خودش را دارد! اینها به این سادگی قابل انتقال نیستند که شخصی عنوان کند: «هر زمان که علاقمند بودیم، ORM مورد استفاده را میشود عوض کرد!»
دلیل دومی که برای تهیه لایه اضافهتری بر روی DbContext عنوان میکنند این است:
«با استفاده از الگوی Repository نوشتن آزمونهای واحد سادهتر میشود». زمانیکه برنامه بر اساس Interfaceها کار میکند میتوان آنها را بجای اشاره به بانک اطلاعاتی، به نمونهای موجود در حافظه، در زمان آزمون تغییر داد.
این مورد در حالت کلی درست است اما .... نه در مورد بانکهای اطلاعاتی!
زمانیکه در یک آزمون واحد، پیاده سازی جدیدی از الگوی Interface مخزن ما تهیه میشود و اینبار بجای بانک اطلاعاتی با یک سری شیء قرارگرفته در حافظه سروکار داریم، آیا موارد زیر را هم میتوان به سادگی آزمایش کرد؟
ارتباطات بین جداولرا، cascade delete، فیلدهای identity، فیلدهای unique، کلیدهای ترکیبی، نوعهای خاص تعریف شده در بانک اطلاعاتی و مسایلی از این دست.
پاسخ: خیر! تغییر انجام شده، سبب کار برنامه با اطلاعات موجود در حافظه خواهد شد، یعنی LINQ to Objects.
شما در حالت استفاده از LINQ to Objects آزادی عمل فوق العادهای دارید. میتوانید از انواع و اقسام متدها حین تهیه کوئریهای LINQ استفاده کنید که هیچکدام معادلی در بانک اطلاعاتی نداشته و ... به ظاهر آزمون واحد شما پاس میشود؛ اما در عمل بر روی یک بانک اطلاعاتی واقعی کار نخواهد کرد.
البته شاید شخصی عنوان که بله میشود تمام اینها نیازمندیها را در حالت کار با اشیاء درون حافظه هم پیاده سازی کرد ولی ... در نهایت پیاده سازی آن بسیار پیچیده و در حد پیاده سازی یک بانک اطلاعاتی واقعی خواهد شد که واقعا ضرورتی ندارد.
و پاسخ صحیح در اینجا و این مساله خاص این است:
لطفا در حین کار با بانکهای اطلاعاتی مباحث mocking را فراموش کنید. بجای SQL Server، رشته اتصالی و تنظیمات برنامه را به SQL Server CE تغییر داده و آزمایشات خود را انجام دهید. پس از پایان کار هم بانک اطلاعاتی را delete کنید. به این نوع آزمونها اصطلاحا integration tests گفته میشود. لازم است برنامه با یک بانک اطلاعاتی واقعی تست شود و نه یک سری شیء ساده قرار گرفته در حافظه که هیچ قیدی همانند شرایط کار با یک بانک اطلاعاتی واقعی، بر روی آنها اعمال نمیشود.
ضمنا باید درنظر داشت بانکهای اطلاعاتی که تنها در حافظه کار کنند نیز وجود دارند. برای مثال SQLite حالت کار کردن صرفا در حافظه را پشتیبانی میکند. زمانیکه آزمون واحد شروع میشود، یک بانک اطلاعاتی واقعی را در حافظه تشکیل داده و پس از پایان کار هم ... اثری از این بانک اطلاعاتی باقی نخواهد ماند و برای این نوع کارها بسیار سریع است.
نتیجه گیری:
حین استفاده از EF code first، الگوی واحد کار، همان DbContext است و الگوی مخزن، همان DbSetها. ضرورتی به ایجاد یک لایه محافظ اضافی بر روی اینها وجود ندارد.
در اینجا بهتر است یک لایه اضافی را به نام مثلا Service ایجاد کرد و تمام اعمال کار با EF را به آن منتقل نمود. سپس در قسمتهای مختلف برنامه میتوان از متدهای این لایه استفاده کرد. به عبارتی در فایلهای Code behind برنامه شما نباید کدهای EF مشاهده شوند. یا در کنترلرهای MVC نیز به همین ترتیب. اینها مصرف کننده نهایی لایه سرویس ایجاد شده خواهند بود.
همچنین بجای نوشتن آزمونهای واحد، به Integration tests سوئیچ کنید تا بتوان برنامه را در شرایط کار با یک بانک اطلاعاتی واقعی تست کرد.
برای مطالعه بیشتر:
emit$:
دو کنترلر به نامهای FirstCtrl و SecondCtrl داریم. FirstCtrl به عنوان والد کنترلر Second است(در این مورد در این پست توضیح داده شده است).
پس فایل html نیز به صورت زیر خواهد بود:
<body ng-app> <div ng-controller="FirstCtrl"> <p>{{title}}</p> <div ng-controller="SecondCtrl"> <button ng-click="onUpdate()">Update First Ctrl Title</button> </div> </div> </body>
function ChildCtrl($scope){ $scope.onUpdate = function(){ this.$emit("Update_Title", "Good Bye"); }; }
function FirstCtrl($scope){ $scope.title= "Hello"; $scope.$on("Update_Title", function(event, message){ $scope.title= message; }); }
»پارامتر دوم سرویس on$ برابر با مقدار جدید ارسال شده توسط سرویس emit$ است.
»نام رویدادی که به عنوان پارامتر به on$ پاس داده میشود باید برابر با نام رویداد پاس داده شده به emit$ باشد.
»میتوان چندین پارامتر را با استفاده از emit$ ارسال کرد و در سرویس on$ با تعریف متغیر به تعداد پارامترها مقادیر آنها را دریافت نمود.
broadcast$
همان طور که مشاهده کردید SecondCtrl در محدوده FirstCtrl تعریف شده است. در نتیجه به راحتی با استفاده از سرویس emit$ توانستیم یک رویداد را منتشر نماییم. اما نکته مهم این است که اگر قصد داشته باشیم یک رویداد را از کنترلر والد (در این جا FirstCtrl است) منتشر نماییم به طوری که در کنترلرهای فرزند قابل دریافت باشد(حرکت رویداد بالا به پایین است)، باید از broadcast$ استفاده کنیم.
»broadcast$ فقط از نظر کاربرد با emit$ متفاوت است و در پیاده سازی کاملا مشابه هستند.
یک مثال:
function ParentCtrl($scope){ $scope.foo = "Hello"; $scope.$on("UPDATE_PARENT", function(event, message){ $scope.title= message; $scope.$broadcast("DO_BIDDING", { buttonTitle : "Taken over", onButtonClick : function(){ $scope.title= "HAHA this button no longer works!"; } }); }); } function ChildCtrl($scope){ $scope.buttonTitle = "Update Parent"; $scope.onButtonClick = function(){ this.$emit("UPDATE_PARENT", "Updated"); }; $scope.$on("DO_BIDDING", function(event, data){ for(var i in data){ $scope[i] = data[i]; } }); }
اگر حالت فرزند و والد بین کنترلرها نباشد چه؟
در این حالت باید rootScope$ را به کنترلر مورد نظر تزریق نمایید و سپس با استفاده از سرویس broadcast$ یا emit$ رویدادتان را منتشر کنید. مثال:
'use strict'; angular.module('myAppControllers', []) .controller('FirstCtrl', function ($rootScope) { $rootScope.$broadcast('UPDATE_ALL'); Or $rootScope.$emit('UPDATE_ALL'); });
از آن جا که حرکت بالا به پایین event bubbling بسیار هزینه برتر است نسبت به حرکت پایین به بالا در نتیجه سعی کنید تا جای ممکن از rootScope$.$broadcast استفاده نکنید. در این جا توضیح کاملی درباره دلایل عدم استفاده از rootScope$.$broadcast داده شده است.
هم چنین میتوانید یک مثال Live را نیز برای مقایسه بین emit$ و broadcast$ در این جا مشاهده کنید.