public interface IRepositoryBase<TEntity> : IReadOnlyRepositoryBase<TEntity> where TEntity : class, IEntity { Task<TEntity> InsertAsync([NotNull] TEntity entity); Task InsertManyAsync([NotNull] IEnumerable<TEntity> entities); Task<TEntity> UpdateAsync([NotNull] TEntity entity); Task UpdateManyAsync([NotNull] IEnumerable<TEntity> entities); // Todo InsertOrUpdate(TEntity entity); Task DeleteAsync([NotNull] TEntity entity); Task DeleteManyAsync([NotNull] IEnumerable<TEntity> entities); } public interface IRepositoryBase<TEntity, TKey> : IRepositoryBase<TEntity>, IReadOnlyRepositoryBase<TEntity, TKey> where TEntity : class, IEntity<TKey> { Task DeleteAsync(TKey id); //TODO: Return true if deleted Task DeleteManyAsync([NotNull] IEnumerable<TKey> ids); }
نوشتن Middleware سفارشی در ASP.NET Core
یک نکتهی تکمیلی: کار با اینترفیس IMiddleware جهت تعریف میانافزارهای سفارشی
اگر امروز قصد تعریف میانافزارهای سفارشی را دارید، بهتر است از روش باز public async Task Invoke(HttpContext context) که در این مطلب معرفی شد، دیگر استفاده نکنید؛ چون مهمترین محدودیتهای آن، داشتن طول عمر Singleton غیرقابل تغییر و همچنین عدم امکان پیاده سازی اینترفیس IDisposable در آن جهت پاکسازی خودکار منابع است. امروز روش توصیه شده، استفاده از اینترفیس IMiddleware است. در این حالت متد Task Invoke فوق، به متد مشخص و ثابت Task InvokeAsync(HttpContext context, RequestDelegate next) تغییر میکند. چون در این حالت دیگر نمیتوان پارامترهای این متد مشخص را مانند قبل که اینترفیسی را پیاده سازی نمیکرد، به صورت پویا کم و زیاد کرد، میتوان سرویسهای مدنظر را به سازندهی کلاس، تزریق کرد. به همین جهت نیاز است، آنرا به نحو زیر به سیستم تزریق وابستگیها معرفی کرد:
builder.Services.AddTransient<MyNewMiddleware>();
این الزام به تعریف آن به صورت یک سرویس رسمی، مزیتهای زیر را به همراه دارد:
الف) میتوان طول عمری، غیر از Singleton را هم در صورت نیاز، تعریف کرد (و مشکل کار با سرویسهایی با طول عمرهای غیر از Singleton کمتر میشود).
ب) چون طول عمر این میانافزار اکنون توسط سیستم تزریق وابستگیها مدیریت میشود، اگر این میانافزار اینترفیس IDisposable را پیاده سازی کند، کار پاکسازی منابع آن خودکار خواهد شد.
نکته 1: روش معرفی آن به سیستم تزریق وابستگیها، به صورت Concrete type است؛ یعنی اصل کلاس باید معرفی شود (مانند سطر فوق) و نه اینکه به صورت متداول زیر به همراه ذکر اینترفیس IMiddleware باشد:
builder.Services.AddTransient<IMiddleware, MyNewMiddleware>();
مابقی کار با آن، با میانافزارهای متداول، تفاوتی ندارد. یعنی قسمت UseMiddleware آن یکی است:
app.UseMiddleware<MyNewMiddleware>();
بنابراین این روش نسبت به روش متداول قبلی، دو تفاوت پیاده سازی اینترفیس مشخص IMiddleware و ثبت کلاس آن به صورت یک سرویس رسمی را دارد؛ مابقی نکات آن، مانند قبل است.
نکته 2: اگر از Scrutor برای ثبت خودکار سرویسهای برنامه استفاده میکنید، روش ثبت خودکار اینگونه سرویسها به صورت زیر و با استفاده از متد ()AsSelf است:
services.Scan(scan => scan.FromAssembliesOf(typeof(IDataSeedersRunner)) .AddClasses(classes => classes.Where(type => { var allInterfaces = type.GetInterfaces(); return allInterfaces.Contains(typeof(IMiddleware)) && allInterfaces.Contains(typeof(ISingletonService)); })) .AsSelf() .WithSingletonLifetime());
در این مثال، تمام IMiddleware هایی که با نشانگر ISingletonService هم مزین شدهاند، یافت شده و به صورت Concrete type هایی، با طول عمر Singleton، به سیستم تزریق وابستگیها اضافه میشوند.
ICriteria API در NHibernate پیاده سازی الگوی Query Object است. مشکلی هم که این روش دارد استفاده از رشتهها جهت ایجاد کوئریهای متفاوت است؛ به عبارتی Type safe نیست. ایرادی هم به آن وارد نیست چون پیاده سازی اولیه آن از جاوا صورت گرفته و مباحث Lambda Expressions و Extension Methods هنوز در آن زبان به صورت رسمی ارائه نشده است (در JDK 7 تحت عنوان Closures قرار است اضافه شود). NHibernate 3.0 از ویژگیهای جدید زبانهای دات نتی جهت ارائهی محصور کنندهای Type safe حول ICriteria API استاندارد به نام QueryOver API سود جسته است. این پیاده سازی بسیار شبیه به عبارات LINQ است اما نباید با آن اشتباه گرفته شود زیرا LINQ to NHibernate یک ویژگی دیگر جدید، یکپارچه و استاندارد NHibernate 3.0 به شمار میرود.
برای نمونه در یک ICriteria query متداول، فراخوانیهای ذیل متداول است:
.Add(Expression.Eq("Name", "Smith"))
.Where<Person>(p => p.Name == "Smith")
مزیتهای این روش (strongly-typed fluent API) به شرح زیر است:
- خبری از رشتهها جهت استفاده از یک خاصیت وجود ندارد. برای مثال در اینجا خاصیت Name کلاس Person تحت کنترل کامپایلر قرار میگیرد و اگر در کلاس Person تغییراتی حاصل شود، برای مثال Name به LName تغییر کند، برنامه دیگر کامپایل نخواهد شد. اما در حالت ICriteria API یا باید به نتایج حاصل از Unit testing مراجعه کرد یا باید به نتایج بازخورد کاربران برنامه مانند: "باز برنامه رو تغییر دادی، یکجای دیگر از کار افتاد!" دقت نمود!
- اگر در حین ویرایش کلاس Person از ابزارهای Refactoring استفاده شود، تغییرات حاصل به صورت خودکار به تمام برنامه نیز اعمال خواهد شد. بدیهی است این اعمال تغییرات تنها در صورتی میسر است که خاصیت مورد نظر به صورت رشته معرفی نگردیده و ارجاعات به اشیاء تعریف شده به سادگی قابل parse باشند.
- در این حالت امکان بررسی نوع خواص تغییر کرده نیز توسط کامپایلر به سادگی میسر است و اگر ارجاعات تعریف شده به نحو صحیحی از این نوع جدید استفاده نکنند باز هم برنامه تا رفع این مشکلات کامپایل نخواهد شد که این هم مزیت مهمی در نگهداری سادهتر یک برنامه است.
- با بکارگیری Extension methods و پیاده سازی Fluent API جدید، مدت زمان یادگیری این روش نیز به شدت کاهش یافته، زیرا Intellisense موجود در VS.NET بهترین راهنمای استفاده از امکانات فراهم شده است. برای مثال جهت استفاده از ویژگی جدید QueryOver به سادگی میتوان پس از ساختن یک session جدید به صورت زیر عمل نمود:
IList<Cat> cats = session.QueryOver<Cat>().Where(c => c.Name == "Max").List();
جهت مشاهدهی معرفی کامل آن میتوان به مستندات NHibernate 3.0 مراجعه کرد.
در مطلب پیشین به پیرامون خود نگاه کردیم و اشیاء گوناگونی را مشاهده کردیم که در حقیقت دنیای ما را تشکیل داده اند و فعالیتهای روزمره ما با استفاده از آنها صورت میگیرد. ایده ای به ذهنمان رسید. اشیاء و مفاهیم مرتبط به آن میتواند روش بهتر و موثرتری برای تقسیم کدهای برنامه باشد. مثلاً اگر کل کدهای برنامه که مسئول حل یکی از مسئلههای کوچک یاد شده است را یکجا بسته بندی کنیم و اصولی که از اشیاء واقعی پیرامون خود آموختیم را در مورد آن رعایت کنیم به برنامه بسیار با کیفیتتری از نظر خوانایی، راحتی در توسعه، اشکال زدایی سادهتر و بسیاری موارد دیگر خواهیم رسید.
توسعه دهندگان زبانهای برنامه نویسی که با ما در این مورد هم عقیده بوده اند دست به کار شده و دستورات و ساختارهای لازم برای پیاده کردن این ایده را در زبان برنامه نویسی قرار دادند و آن را زبان برنامه نویسی شیء گرا نامیدند. حتی جهت برخورداری از قابلیت استفاده مجدد از کد و موارد دیگر به جای آنکه کدها را در بسته هایی به عنوان یک شیء خاص قرار دهیم آنها را در بسته هایی به عنوان قالب یا نقشه ساخت اشیاء خاصی که در ذهن داریم قرار میدهیم. یعنی مفهوم کلاس یا رده که پیشتر اشاره شد. به این ترتیب یک بار مینویسیم و بارها استفاده میکنیم. مانند همان مثال بازیکن در بخش نخست. هر زمان که لازم باشد با استفاده از دستورات مربوطه از روی کدهای کلاس که نقشه یا قالب ساخت اشیاء هستند شیء مورد نظر را ساخته و در جهت حل مسئله مورد نظر به کار میبریم.
حال برای آنکه به طور عملی بتوانیم از ایده شیء گرایی در برنامه هایمان استفاده کنیم و مسائل بزرگ را حل کنیم لازم است ابتدا مقداری با جزییات و دستورات زبان در این مورد آشنا شویم.
تذکر: دقت کنید برای آنکه از ایده شیء گرایی در برنامهها حداکثر استفاده را ببریم مفاهیمی در مهندسی نرم افزار به آن اضافه شده است که ممکن است در دنیای واقعی نیازی به طرح آنها نباشد. پس لطفاً تلاش نکنید با دیدن هر مفهوم تازه بلافاصله سعی در تطبیق آن با محیط اطراف کنید. هر چند بسیاری از آنها به طور ضمنی در اشیاء پیرامون ما نیز وجود دارند.
زبان برنامه نویسی مورد استفاده برای بیان مفاهیم برنامه نویسی در این سری مقالات زبان سی شارپ است. اما درک برنامههای نوشته شده برای علاقه مندان به زبانهای دیگری مانند وی بی دات نت نیز دشوار نیست. چراکه اکثر دستورات مشابه است و تبدیل Syntax نیز به راحتی با اندکی جستجو میسر میباشد. لازم به یادآوری است زبان سی شارپ به بزرگی یا کوچکی حروف حساس است.
تشخیص و تعریف کلاسهای برنامه
کار را با یک مثال شروع میکنیم. فرض کنید به عنوان بخشی از راه حل یک مسئله بزرگ، لازم است محیط و مساحت یک سری چهارضلعی را محاسبه کنیم و قصد داریم این وظیفه را به طور کامل بر عهده قطعه کدهای مستقلی در برنامه قرار دهیم. به عبارت دیگر قصد داریم متناظر با هر یک از چهارضلعیهای موجود در مسئله یک شیء در برنامه داشته باشیم که قادر است محیط و مساحت خود را محاسبه و ارائه نماید. کلاس زیر که با زبان سی شارپ نوشته شده امکان ایجاد اشیاء مورد نظر را فراهم میکند.public class Rectangle { public double Width; public double Height; public double Area() { return Width*Height; } public double Perimeter() { return 2*(Width + Height); } }
در این قطعه برنامه نکات زیر قابل توجه است:
- کلاس با کلمه کلیدی class تعریف میشود.
- همان طور که مشاهده میکنید تعریف کلاس با کلمه public آغاز شده است. این کلمه محدوده دسترسی به کلاس را تعیین میکند. در اینجا از کلمه public استفاده کردیم تا بخشهای دیگر برنامه امکان استفاده از این کلاس را داشته باشند.
- پس از کلمه کلیدی class نوبت به نام کلاس میرسد. اگرچه انتخاب نام مورد نظر امری اختیاری است اما در آینده حتماً اصول و قراردادهای نامگذاری در داتنت را مطالعه نمایید. در حال حاضر حداقل به خاطر داشته باشید تا انتخاب نامی مناسب که گویای کاربرد کلاس باشد بسیار مهم است.
- باقیمانده کد، بدنه کلاس را تشکیل میدهد. جاییکه ویژگی ها، رفتارها و ... یا به طور کلی اعضای کلاس تعریف میشوند.
ایجاد شیء از یک کلاس و نحوه دسترسی به شیء ایجاد شده
شیء و کلاس چیزهای متفاوتی هستند. یک کلاس نوع یک شیء را تعریف میکند. اما یک شیء یک موجودیت عینی و واقعی بر اساس یک کلاس است. در اصطلاح از شیء به عنوان یک نمونه (Instance) یا وهله ای از کلاس مربوطه یاد میکنیم. همچنین به عمل ساخت شیء نمونه سازی یا وهله سازی گوییم.برای ایجاد شیء از کلمه کلیدی new و به دنبال آن نام کلاسی که قصد داریم بر اساس آن یک شیء بسازیم استفاده میکنیم. همان طور که اشاره شد کلاس یک نوع را تعریف میکند. پس از آن میتوان همانند سایر انواع مانند int, string, … برای تعریف متغیر استفاده نمود. به مثال زیر توجه کنید.
Rectangle rectangle = new Rectangle();
Rectangle rectangle;
Rectangle rectangle1 = new Rectangle(); Rectangle rectangle2 = rectangle1;
حالا میتوان شیء ساخته شده را با استفاده از ارجاعی که به آن داریم به کار برد.
Rectangle rectangle = new Rectangle(); rectangle.Width = 10.5; rectangle.Height = 10; double a = rectangle.Area();
فیلدها
اگر به تعریف کلاس دقت کنید مشخص است که دو متغییر Width و Height را با سطح دسترسی عمومی تعریف کرده ایم.به متغیرهایی از هر نوع که مستقیماً درون کلاس تعریف شوند (و نه مثلاً داخل یک تابع درون کلاس) فیلد میگوییم. فیلدها از اعضای کلاس دربردارنده آنها محسوب میشوند.
تعریف فیلدها مستقیماً در بدنه کلاس با یک Access Modifier شروع میشود و به دنبال آن نوع فیلد و سپس نام دلخواه برای فیلد میآید.
تذکر: نامگذاری مناسب یکی از مهمترین اصولی است که یک برنامه نویس باید همواره به آن توجه کافی داشته باشد و به شدت در بالا رفتن کیفیت برنامه موثر است. به خاطر داشته باشید تنها اجرا شدن و کار کردن یک برنامه کافی نیست. رعایت بسیاری از اصول مهندسی نرم افزار که ممکن است نقش مستقیمی در کارکرد برنامه نداشته باشند موجب سهولت در نگهداری و توسعه برنامه شده و به همان اندازه کارکرد صحیح برنامه مهم هستند. بنابراین مجدداً شما را دعوت به خواندن مقاله یاد شده بالا در مورد اصول نامگذاری صحیح میکنم. هر مفهوم تازه ای که میآموزید میتوانید به اصول نامگذاری همان مورد در مقاله پیش گفته مراجعه نمایید. همچنین افزونه هایی برای Visual Studio وجود دارد که شما را در زمینه نامگذاری صحیح و بسیاری موارد دیگر هدایت میکنند که یکی از مهمترین آنها Resharper نام دارد.
مثال:
// public field (Generally not recommended.) public double Width;
فیلدها معمولاً با سطح دسترسی خصوصی و برای نگهداری از دادههایی که مورد نیاز بیش از یک متد (یا تابع) درون کلاس است و آن دادهها باید پس از خاتمه کار یک متد همچنان باقی بمانند استفاده میشود. بدیهی است در غیر اینصورت به جای تعریف فیلد میتوان از متغیرهای محلی (متغیری که درون خود تابع تعریف میشود) استفاده نمود.
همان طور که پیشتر اشاره شد برای دسترسی به یک فیلد ابتدا یک نقطه پس از نام شیء درج کرده و سپس نام فیلد مورد نظر را مینویسیم.
Rectangle rectangle = new Rectangle(); rectangle.Width = 10.5;
public class Rectangle { public double Width = 5; // ... }
متدها
متدها قطعه کدهایی شامل یک سری دستور هستند. این مجموعه دستورات با فراخوانی متد و تعیین آرگومانهای مورد نیاز اجرا میشوند. در زبان سی شارپ به نوعی تمام دستورات در داخل متدها اجرا میشوند. در این زبان تمامی توابع در داخل کلاسها تعریف میشوند و بنابراین همه متد هستند.متدها نیز مانند فیلدها در داخل کلاس تعریف میشوند. ابتدا یک Access Modifier سطح دسترسی را تعیین مینماید. سپس به ترتیب نوع خروجی، نام متد و لیست پارامترهای آن در صورت وجود درج میشود. به مجموعه بخشهای یاد شده امضای متد میگویند.
پارامترهای یک متد داخل یک جفت پرانتز قرار میگیرند و با کاما (,) از هم جدا میشوند. یک جفت پرانتز خالی نشان دهنده آن است که متد نیاز به هیچ پارامتری ندارد.
بار دیگر به بخش تعریف متدهای کلاسی که ایجاد کردیم توجه نمایید.
public class Rectangle { // ... public double Area() { return Width*Height; } public double Perimeter() { return 2*(Width + Height); } }
همچنین توجه نمایید این شیء برای محاسبه مساحت و محیط خود نگاهی به ویژگیهای خود یعنی عرض و ارتفاعش که در فیلدهای آن نگهداری میکنیم میاندازد.
فراخوانی متد یک شیء همانند دسترسی به فیلد آن است. ابتدا نام شیء سپس یک نقطه و به دنبال آن نام متد مورد نظر به همراه پرانترها. آرگومانهای مورد نیاز در صورت وجود داخل پرانتزها قرار میگیرند و با کاما از هم جدا میشوند. که البته در این مثال متد ما نیازی به آرگومان ندارد. به همین دلیل برای فراخوانی آن تنها یک جفت پرانتز خالی قرار میدهیم.
در این بخش به دو مفهوم پارامتر و آرگومان اشاره شد. تفاورت آنها چیست؟
در هنگام تعریف یک متد نام و نوع پارامترهای مورد نیاز را تعیین و درج مینماییم. حال وقتی قصد فراخوانی متد را داریم باید مقادیر واقعی که آرگومان نامیده میشود را برای هر یک از پارامترهای تعریف شده فراهم نماییم. نوع آرگومان باید با نوع پارامتر تعریف شده تطبیق داشته باشد. اما اگر یک متغیر را به عنوان آرگومان در هنگام فراخوانی متد استفاده میکنیم نیازی به یکسان بودن نام آن متغیر و نام پارامتر تعریف شده نیست.
متدها میتوانند یک مقدار را به کدی که آن متد را فراخوانی کرده است بازگشت دهند.
Rectangle rectangle = new Rectangle(); rectangle.Width = 10.5; rectangle.Height = 10; double p = rectangle.Perimeter();
نکته: کلمه return علاوه بر بازگشت مقدار مورد نظر سبب پایان اجرای متد نیز میشود. حتی در صورتی که نوع خروجی یک متد void تعریف شده باشد استفاده از کلمه return بدون اینکه مقداری به دنبال آن بیاید میتواند برای پایان اجرای متد، در صورت نیاز و مثلاً برقراری شرطی خاص مفید باشد. بدون کلمه return متد زمانی پایان مییابد که به پایان قطعه کد بدنه خود برسد. توجه نمایید که در صورتی که نوع خروجی متد چیزی به جز void است استفاده از کلمه return به همراه مقدار مربوطه الزامی است.
مقدار خروجی یک متد را میتوان هر جایی که مقداری از همان نوع مناسب است مستقیماً به کار برد. همچنین میتوان آن را در یک متغیر قرار داد و سپس از آن استفاده نمود.
به عنوان مثال کلاس ساده زیر را در نظر بگیرید که متدی دارد برای جمع دو عدد.
public class SimpleMath { public int AddTwoNumbers(int number1, int number2) { return number1 + number2; } }
SimpleMath obj = new SimpleMath(); Console.WriteLine(obj.AddTwoNumbers(1, 2)); int result = obj.AddTwoNumbers(1, 2); Console.WriteLine(result);
در بخشهای بعدی بحث ما در مورد سایر اعضای کلاس و برخی جزییات پیرامون اعضای پیش گفته خواهد بود.
ASP.NET MVC #1
چرا ASP.NET MVC ؟
با وجود فریم ورک پختهای به نام ASP.NET web forms، اولین سؤالی که حین سوئیچ به ASP.NET MVC مطرح میشود این است: «برای چی؟». بنابراین تا به این سؤال پاسخ داده نشود، هر نوع بحث فنی در این مورد بی فایده است.
مزایای ASP.NET MVC نسبت به ASP.NET web forms
1) سادگی نوشتن آزمونهای واحد
مهمترین دلیل استفاده از ASP.NET MVC صرفنظر از تمام دلایل دیگر، بحث طراحی ویژه آن جهت ساده سازی تهیه آزمونهای واحد است. مشکل اصلی نوشتن آزمونهای واحد برای برنامههای ASP.NET web forms، درگیر شدن مستقیم با تمام جزئیات طول عمر یک صفحه است. به علاوه فایلهای code behind هر چند به ظاهر کدهای منطق یک صفحه را از کدهای HTML مانند آن جدا میکنند اما در عمل حاوی ارجاعات مستقیمی به تک تک عناصر بصری موجود در صفحه هستند (حس غلط جدا سازی کدها از اجزای یک فرم). اگر قرار باشد برای این وب فرمها و صفحات، آزمون واحد بنویسیم باید علاوه بر شبیه سازی چرخه طول عمر صفحه و همچنین رخدادهای رسیده، کار وهله سازی تک تک عناصر بصری را نیز عهده دار شویم. اینجا است که ASP.NET web forms گزینهی مطلوبی برای این منظور نخواهد بود و اگر نوشتن آزمون واحد برای آن غیرممکن نباشد، به همین دلایل آنچنان مرسوم هم نیست.
البته شاید بپرسید که این مساله چه اهمیتی دارد؟ امکان نوشتن سادهتر آزمونهای واحد مساوی است با امکان سادهتر اعمال تغییرات به یک پروژه بزرگ. تغییرات در پروژههای بزرگی که آزمون واحد ندارند واقعا مشکل است. یک قسمت را تغییر میدهید، 10 قسمت دیگر به هم میریزند. اینجا است که مدام باید به کارفرما گفت: «نه!»، «نمیشه!» یا به عبارتی «نمیتونم پروژه رو جمع کنم!» چون نمیتونم سریع برآورد کنم که این تغییرات کدام قسمتها را تحت تاثیر قرار میدهند، کجا به هم ریخت. من باید خودم سریع بتونم مشخص کنم با این تغییر جدید چه قسمتهایی به هم ریخته تا اینکه دو روز بعد زنگ بزنند: «باز جایی رو تغییر دادی، یکجای دیگر کار نمیکنه!»
2) دستیابی به کنترل بیشتر بر روی اجزای فریم ورک
در طراحی ASP.NET MVC همهجا interface ها قابل مشاهد هستند. همین مساله به معنای افزونه پذیری اکثر قطعات تشکیل دهنده ASP.NET MVC است؛ برخلاف ASP.NET web forms. برای مثال تابحال چندین view engine، routing engine و غیره توسط برنامه نویسهای مستقل برای ASP.NET MVC طراحی شدهاند که هیچکدام با ASP.NET web forms میسر نیست. برای مثال از view engine پیش فرض آن خوشتان نمیآید؟ عوضش کنید! سیستم اعتبار سنجی توکار آنرا دوست ندارید؟ آنرا با یک نمونه بهتر تعویض کنید و الی آخر ...
به علاوه طراحی بر اساس interface ها یک مزیت دیگر را هم به همراه دارد و آن هم ساده سازی mocking (تقلید) آنها است جهت ساده سازی نوشتن آزمونهای واحد.
3) سرعت بیشتر اجرا
ASP.NET MVC یک سری از قابلیتهای ذاتی ASP.NET web forms را مانند ViewState حذف کرده است. اگر وب را جستجو کنید، برنامه نویسهای ASP.NET web forms مدام از این مساله شکایت دارند و راه حلهای مختلفی را جهت حذف یا فشرده سازی آن ارائه میدهند. ViewState در ابتدای امر جهت شبیه سازی محیط دسکتاپ در وب درنظر گرفته شده بود و مهاجرت سادهتر برنامه نویسهای VB6 به وب، اما واقعیت این است که اگر یک برنامه نویس ASP.NET web forms به اندازه آن توجهی نداشته باشد، ممکن است حجم آن در یک صفحه پیچیده تا 500 کیلوبایت یا بیشتر هم برسد. همین مساله بر روی سرعت دریافت و اجرا تاثیر گذار خواهد بود.
4) کنترلهای ASP.NET web forms آنچنان آش دهنسوزی هم نیستند!
خوب، ViewState حذف شده، بنابراین اکثر کنترلهای ASP.NET web forms هم کاربرد آنچنانی در ASP.NET MVC نخواهند داشت؛ اما واقعیت این است که اکثر اوقات اگر شروع به سفارشی سازی یک کنترل توکار ASP.NET web forms کنید تا مطابق نیازهای کاری شما رفتار کند، پس از مدتی به یک کنترل کاملا از نو بازنویسی شده خواهید رسید! بنابراین در ابتدای امر تا 80 درصد کار اینطور به نظر میرسد که به عجب سرعت بالایی در توسعه دست یافتهایم، اما هنگامیکه قرار است این 20 درصد پایانی را پر کنیم، به این نتیجه خواهیم رسید که این کنترلها با این وضع ابتدایی که دارند قابل استفاده نیستند و نیاز به دستکاری قابل ملاحظهای دارند تا نیازهای واقعی کاری را برآورده کنند.
5) کنترل کامل بر روی HTML نهایی تولیدی
اگر علاقمند به کار با jQuery باشید، مدام نیاز خواهید تا با ID کنترلها و عناصر صفحه کار کنید. پیشتر ASP.NET web forms این ID را یک طرفه و به صورت مقدار منحصربفردی تولید میکرد که جهت کار با فریم ورکهای جاوا اسکریپتی عموما مشکل ساز بود. البته ASP.NET web forms در نگارشهای جدید خود مشکل عدم امکان مقدار دهی ClientId سفارشی را برای کنترلهای وب خود برطرف کرده است و این مورد را میتوان دستی هم تنظیم کرد ولی در کل باز هم آنچنان کنترلی رو خروجی HTML نهایی کنترلهای تولیدی نیست مگر اینکه مانند مورد چهارم یاد شده یک کنترل را از صفر بازنویسی کنید!
همچنین اگر باز هم بیشتر با jQuery و ASP.NET web forms کار کرده باشید میدانید که jQuery آنچنان سنخیتی با ViewState و Postback وب فرمها ندارد و همین مساله عموما مشکلزا است. علاوه بر آن اخیرا مایکروسافت توسعه ASP.NET Ajax خود را تقریبا در حالت تعلیق و واگذار شده به شرکتهای ثالث درآورده است و توصیه آنها استفاده از jQuery Ajax است. اینجا است که مدل ASP.NET MVC سازگاری کاملی را با jQuery Ajax دارد هم از لحاظ نبود ViewState و هم از جنبهی کنترل کامل بر روی markup نهایی تولیدی.
یا برای مثال خروجی پیش فرض یک GridView، جدول HTML ایی است که این روزها همهجا علیه آن صحبت میشود. البته یک سری آداپتور CSS friendly برای اکثر این کنترلها موجود است و ... باز هم دستکاری بیش از حد کنترلهای پیش فرض جهت رسیدن به خروجی دلخواه. تمام اینها را در ASP.NET MVC میشود با معادلهای بسیار باکیفیت افزونههای jQuery جایگزین کرد و از همه مهمتر چون ViewState و مفاهیمی مانند PostBack حذف شده، استفاده از این افزونهها مشکل ساز نخواهد بود.
6) استفاده از امکانات جدید زبانهای دات نتی
طراحی اصلی ASP.NET web forms مربوط است به دوران دات نت یک؛ زمانیکه نه Generics وجود داشت، نه LINQ و نه آنچنان مباحث TDD یا استفاده از ORMs متداول بود. برای مثال شاید ایجاد یک strongly typed web form الان کمی دور از ذهن به نظر برسد، زمانیکه اصل آن بر مبنای بکارگیری گسترده datatable و dataset بوده است (با توجه به امکانات زبانهای دات نتی در آن دوران). بنابراین اگر علاقمند هستید که این امکانات جدید را بکاربگیرید، ASP.NET MVC برای استفاده از آنها طراحی شده است!
7) از ASP.NET web forms سادهتر است
طراحی ASP.NET MVC بر اساس ایده Convention over configuration است. به این معنا که اجزای آن بر اساس یک سری قرار داد در کنار هم مشغول به کار هستند. مشخص است View باید کجا باشد، نام کنترلرها چگونه باید تعیین شوند و قرار داد مرتبط به آن چیست، مدل باید کجا قرار گیرد، قرار داد پردازش آدرسهای صفحات سایت به چه نحوی است و الی آخر. خلاصه در بدو امر با یک فریم ورک حساب شده که شما را در مورد نحوه استفاده صحیح از آن راهنمایی میکند، مواجه هستید.
به همین ترتیب هر پروژه MVC دیگری را هم که مشاهده کنید، سریع میتوانید تشخیص دهد قراردادهای بکارگرفته شده در آن چیست. بنابراین اگر قرار است ASP.NET را امروز شروع کنید و هیچ سابقهای هم از وب فرمها ندارید، یک راست با ASP.NET MVC شروع کنید.
8) محدود به پیاده سازی مایکروسافت نیست
پیاده سازیهای مستقلی هم از ASP.NET MVC توسط اشخاص و گروههای خارج از مایکروسافت وجود دارد: ^، ^، ^، ^ و ...
و در پایان یکی دیگر از دلایل سوئیچ به ASP.NET MVC ، «یاد گرفتن یک چیز جدید است» یا به عبارتی فرا گرفتن یک روش دیگر برای حل مسایل، هیچگاه ضرری را به همراه نخواهد داشت که هیچ، بلکه باعث بازتر شدن میدان دید نیز خواهد گردید.
یک دیدگاه دیگر
ASP.NET MVC برای شما مناسب نخواهد بود اگر ...
1) با پلیمرفیزم مشکل دارید.
ASP.NET MVC پر است از interfaces، abstract classes، virtual methods و امثال آن. بنابراین اگر تازه کار هستید، ابتدا باید مفاهیم شیءگرایی را تکمیل کنید.
2) اگر نمیتوانید فریم ورک خودتون رو بر پایه ASP.NET MVC بنا کنید!
ASP.NET MVC برخلاف وب فرمها به همراه آنچنان تعداد بالایی کنترل و افزونه از پیش مهیا شده نیست. در بدو امر شما فقط یک سری url helper، html helper و ajax helper ساده را خواهید دید؛ این نقطه ضعف ASP.NET MVC نیست. عمدا به این نحو طراحی شده است. همانطور که عنوان شد اکثر اجزای این فریم ورک قابل تعویض است. بنابراین دست شما را باز گذاشته است تا با پیاده سازی این اینترفیسها، امکانات جدیدی را خلق کنید. البته پس از این چندین و چند سال که از ارائه آن میگذرد، به اندازه کافی افزونه برای ASP.NET MVC طراحی شده است که به هیچ عنوان احساس کمبود نکنید یا اینکه نیازی هم نداشته باشید تا آنچنان فریم ورک خاصی را بر پایه ASP.NET MVC تهیه کنید. برای مثال پروژه MvcContrib موجود است یا شرکت telerik یک مجموعه سورس باز کامل مخصوص ASP.NET MVC را ارائه داده است و الی آخر.
3) اگر نمیتوانید از کتابخانههای سورس باز استفاده کنید.
همانطور که عنوان شد ASP.NET MVC به همراه کوهی از کنترلها ارائه نشده است. اکثر افزونههای آن سورس باز هستند و کار با آنها هم دنیای خاص خودش را دارد. چگونه باید کتابخانههای مناسب را پیدا کرد، کجا سؤال پرسید، کجا باگ گزارش داد، چگونه مشارکت کرد و غیره. خلاصه منتظر یک بسته شکیل حاضر و آماده نباید بود. خود ASP.NET MVC هم تحت مجوز MSPL به صورت سورس باز در دسترس است.
و یک نکته تکمیلی
مایکروسافت مدتی است شروع کرده به پرورش و زمزمه ایده «یک ASP.NET واحد». به عبارتی قصد دارند در یکی دو نگارش بعد، این دو (وب فرم و MVC) را یکی کنند. هم اکنون اگر مطالب وبلاگها را مطالعه کنید زیرساخت آن به نام ASP.NET Web API آماده شده است و در مرحله بتا است. نکته جالب اینجا است که این Web API امکان تعریف یکپارچه و مستقیم کنترلرهای MVC را در وب فرمها میسر میکند. ولی باز هم نام آن Controller است یعنی جزئی از ASP.NET MVC و کسی میتواند از آن استفاده کند که با MVC مشکلی نداشته باشد. بنابراین یادگیری MVC هیچ ضرری نخواهد داشت و جای دوری نخواهد رفت!
- جداول تعاریف Definition Table
- جداول ارجاع References Table
- جداول manifest
جداول تعریف
جدول زیر تعدادی از جداول تعریفها را توضیح میدهد:
ModuleDef | شامل آدرس یا مدخلی است که ماژول در آن تعریف شده است. این آدرس شامل نام ماژول به همراه پسوند آن است؛ بدون ذکر مسیر. در صورتی که کامپایل به صورت GUID انجام گرفته باشد، Version ID ماژول هم همراه آنها خواهد بود. در صورتیکه نام فایل تغییر کند، این جدول باز نام اصلی ماژول را به همراه خواهد داشت. هر چند تغییر نام فایل به شدت رد شده و ممکن است باعث شود CLR نتواند در زمان اجرا آن را پیدا کند. |
TypeDef | شامل یک مدخل ورودی برای هر نوعی است که تعریف شده است. هر آدرس ورودی شامل نام نوع ، پرچمها (همان مجوزهای public و private و ...) میباشد. همچنین شامل اندیس هایی به متدها است که شامل جدول MethodDef میباشند یا فیلدهایی که شامل جدول FieldDef میباشند و الی آخر... |
MethodDef | شامل آدرسی برای هر متد تعریف شده در ماژول است که شامل نام متد و پرچم هاست. همچنین شامل امضای متد و نقطهی آغاز کد IL آن در ماژول هم میشود و آن آدرس هم میتواند ارجاعی به جدول ParamDef جهت شناسایی پارامترها باشد. |
FieldDef | شامل اطلاعاتی در مورد فیلدهاست که این اطلاعات ، پرچم، نام و نوع فیلد را مشخص میکنند. |
ParamDef | حاوی اطلاعات پارامتر متدهاست که این اطلاعات شامل پرچمها (in , out ,retval) ، نوع و نام است. |
PropertyDef | برای هر پراپرتی یا خصوصیت، شامل یک آدرس است که شامل نام، نوع و پرچم میشود. |
EventDef | برای هر رویداد شامل یک آدرس است که این آدرس شامل نام و نوع است. |
جداول ارجاعی
AssemblyRef | شامل آدرس اسمبلی است که ماژولی به آن ارجاع داده است و این آدرس شامل اطلاعات ضروری جهت اتصال به اسمبلی میشود و این اطلاعات شامل نام اسمبلی (بدون ذکر پسوند و مسیر)، شماره نسخه اسمبلی، سیستم فرهنگی و منطقهای تعیین شده اسمبلی culture و یک کلید عمومی که عموما توسط ناشر ایجاد میگردد که هویت ناشر آن اسمبلی را مشخص میکند. هر آدرس شامل یک پرچم و یک کد هش هست که بری ارزیابی از صحت و بی خطا بودن بیتهای اسمبلی ارجاع شده Checksum استفاده میشود. |
ModuleRef | شامل یک آدرس ورودی به هدر PE ماژول است به نوعهای پیاده سازی شده آن ماژول در آن اسمبلی. هر آدرس شامل نام فایل و پسوند آن بدون ذکر مسیر است. این جدول برای اتصال به نوعهایی استفاده میشود که در یک ماژول متفاوت از ماژول اسمبلی صدا زده شده پیاده سازی شده است. |
TypeRef | شامل یک آدرس یا ورودی برای هر نوعی است که توسط ماژول ارجاع داده شده است. هر آدرس شامل نام نوع و آدرسی است که نوع در آن جا قرار دارد. اگر این نوع داخل نوع دیگری پیاده سازی شود، ارجاعات به سمت یک جدول TypeDef خواهد بود. اگر نوع داخل همان ماژول تعریف شده باشد، ارجاع به سمت جدول ModuleDef خواهد بود و اگر نوع در ماژول دیگری از آن اسمبلی پیاده سازی شده باشد، ارجاع به سمت یک جدول ModuleRef خواهد بود و اگر نوع در یک اسمبلی جداگانه تعریف شده باشد، ارجاع به جدول AssemblyRef خواهد بود. |
MemberRef | شامل یک آدرس ورودی برای هر عضو (فیلد و متدها و حتی پراپرتی و رویدادها) است که توسط آن آن ماژول ارجاع شده باشد. هر آدرس شامل نام عضو، امضاء و یک اشارهگر به جدول TypeRef است، برای نوعهایی که به تعریف عضو پرداختهاند. |
ILDasm Program.exe
View/MetaInfo/Show
=========================================================== ScopeName : Program.exe MVID : {CA73FFE80D424610A8D39276195C35AA} =========================================================== Global functions Global fields Global MemberRefs TypeDef #1 (02000002) TypDefName: Program (02000002) Flags : [Public] [AutoLayout] [Class] [Sealed] [AnsiClass] [BeforeFieldInit] (00100101) Extends : 01000001 [TypeRef] System.Object Method #1 (06000001) [ENTRYPOINT] MethodName: Main (06000001) Flags : [Public] [Static] [HideBySig] [ReuseSlot] (00000096) RVA : 0x00002050 ImplFlags : [IL] [Managed] (00000000) CallCnvntn: [DEFAULT] ReturnType: Void No arguments. Method #2 (06000002) MethodName: .ctor (06000002) Flags : [Public] [HideBySig] [ReuseSlot] [SpecialName] [RTSpecialName] [.ctor] (00001886) RVA : 0x0000205c ImplFlags : [IL] [Managed] (00000000) CallCnvntn: [DEFAULT] hasThis ReturnType: Void No arguments. TypeRef #1 (01000001) Token: 0x01000001 ResolutionScope: 0x23000001 TypeRefName: System.Object MemberRef #1 (0a000004) Member: (0a000004) .ctor: CallCnvntn: [DEFAULT] hasThis ReturnType: Void No arguments. TypeRef #2 (01000002) Token: 0x01000002 ResolutionScope: 0x23000001 TypeRefName: System.Runtime.CompilerServices.CompilationRelaxationsAttribute MemberRef #1 (0a000001) Member: (0a000001) .ctor: CallCnvntn: [DEFAULT] hasThis ReturnType: Void 1 Arguments Argument #1: I4 TypeRef #3 (01000003) Token: 0x01000003 ResolutionScope: 0x23000001 TypeRefName: System.Runtime.CompilerServices.RuntimeCompatibilityAttribute MemberRef #1 (0a000002) Member: (0a000002) .ctor: CallCnvntn: [DEFAULT] hasThis ReturnType: Void No arguments. TypeRef #4 (01000004) Token: 0x01000004 ResolutionScope: 0x23000001 TypeRefName: System.Console MemberRef #1 (0a000003) Member: (0a000003) WriteLine: CallCnvntn: [DEFAULT] ReturnType: Void 1 Arguments Argument #1: String Assembly Token: 0x20000001 Name : Program Public Key : Hash Algorithm : 0x00008004 Version: 0.0.0.0 Major Version: 0x00000000 Minor Version: 0x00000000 Build Number: 0x00000000 Revision Number: 0x00000000 Locale: <null> Flags : [none] (00000000) CustomAttribute #1 (0c000001) CustomAttribute Type: 0a000001 CustomAttributeName: System.Runtime.CompilerServices.CompilationRelaxationsAttribute :: instance void .ctor(int32) Length: 8 Value : 01 00 08 00 00 00 00 00 > < ctor args: (8) CustomAttribute #2 (0c000002) CustomAttribute Type: 0a000002 CustomAttributeName: System.Runtime.CompilerServices.RuntimeCompatibilityAttribute :: instance void .ctor() Length: 30 Value : 01 00 01 00 54 02 16 57 72 61 70 4e 6f 6e 45 78 > T WrapNonEx< : 63 65 70 74 69 6f 6e 54 68 72 6f 77 73 01 >ceptionThrows < ctor args: () AssemblyRef #1 (23000001) Token: 0x23000001 Public Key or Token: b7 7a 5c 56 19 34 e0 89 Name: mscorlib Version: 4.0.0.0 Major Version: 0x00000004 Minor Version: 0x00000000 Build Number: 0x00000000 Revision Number: 0x00000000 Locale: <null> HashValue Blob: Flags: [none] (00000000) User Strings 70000001 : ( 2) L"Hi" Coff symbol name overhead: 0
View/statistics
File size : 3584 PE header size : 512 (496 used) (14.29%) PE additional info : 1411 (39.37%) Num.of PE sections : 3 CLR header size : 72 ( 2.01%) CLR metadata size : 612 (17.08%) CLR additional info : 0 ( 0.00%) CLR method headers : 2 ( 0.06%) Managed code : 20 ( 0.56%) Data : 2048 (57.14%) Unaccounted : 1093 (30.50%) Num.of PE sections : 3 .text 1024 .rsrc 1536 .reloc 512 CLR metadata size : 612 Module 1 (10 bytes) TypeDef 2 (28 bytes) 0 interfaces, 0 explicit layout TypeRef 4 (24 bytes) MethodDef 2 (28 bytes) 0 abstract, 0 native, 2 bodies MemberRef 4 (24 bytes) CustomAttribute 2 (12 bytes) Assembly 1 (22 bytes) AssemblyRef 1 (20 bytes) Strings 184 bytes Blobs 68 bytes UserStrings 8 bytes Guids 16 bytes Uncategorized 168 bytes CLR method headers : 2 Num.of method bodies 2 Num.of fat headers 0 Num.of tiny headers 2 Managed code : 20 Ave method size 10
اکثر مواقع برنامه نویسان برای بازگشت چند مقدار توسط یک متد، به روشهایی مثل تعریف کلاسهای POCO یا پارامترهایی از نوع out متوسل میشوند. به وسیلهی Tupleها میتوان چند مقدار مختلف را به عنوان خروجی متد بازگشت داد:
private Tuple<string, string, int> GetPersonInfo() { return new Tuple<string, string, int>("Steve", "Jobs", 56); }
عدم نیاز به استفاده از کالکشنهای موقتی در متدها جهت نگهداری مقدار بازگشتی متد
اکثر برنامه نویسان، در متدهایی که لیستی از مقادیر را بازگشت میدهند، از یک متغییر موقتی استفاده میکنند:
private IEnumerable<int> GetNumbers() { var result = new List<int>(); for (int i = 0; i <= 100; i++) result.Add(i); return result; }
private IEnumerable<int> GetNumbers() { for (int i = 0; i <= 100; i++) { yield return i; } }
ملزم کردن نوع پایه یک کلاس Generic به رعایت قوانین پیاده سازی خاص
Genericها میتوانند عملکرد یکسانی را برای نوعهای دادهای متفاوت، پیاده سازی کنند. با توجه به ماهیت Genericها ممکن است در سناریوهایی لازم باشد تا نوع دادهی اولیهای که قرار است Generic پیاده سازی شود، از قوانین پیاده سازی خاصی پیروی کند. به صورت زیر میتوان نوع پایهی یک Generic را ملزم به رعایت قوانین خاص پیاده سازی به واسطه یک Interface کرد:
public interface ICar { string GetName(); string GetManufacturerCompany(); } private class GenricClass<T> where T : ICar { }
public class Audi : ICar { public string GetName() { throw new NotImplementedException(); } public string GetManufacturerCompany() { throw new NotImplementedException(); } } private static void Main(string[] args) { var invalidTest = new GenricClass<int>(); var validTest = new GenricClass<Audi>(); }
- اگر از یک سیستم تزریق وابستگیها استفاده میکنید، مطلب جاری را فراموش کنید. یک کلاس معمولی را ایجاد کرده و یک اینترفیس را از آن استخراج کنید (مانند همیشه و بسیار عادی). سپس این اینترفیس و کلاس پیاده سازی کنندهی آنرا با «طول عمر» singleton به این IoC Container معرفی کنید (مهم نیست نام آن IoC Container چیست. این روش همه جا کار میکند). اکنون چون مدیریت طول عمر این سرویس توسط IoC container مورد استفاده کنترل میشود، میتوانید در سازندهی آن تمام سرویسهای دیگر را هم تزریق کرده (مانند تمام سرویسهای دیگر تعریف شده) و استفاده کنید؛ چون وهله سازی و مدیریت طول عمر آن توسط خود Container مدیریت میشود.
تعریف موجودیت و DbSet تصاویر یک اتاق هتل
برای اینکه بتوان اطلاعات تصاویر آپلودی را در بانک اطلاعاتی ثبت کرد، نیاز است یک رابطهی یک به چند را بین یک اتاق و تصاویر مرتبط با آن برقرار کرد. به همین جهت ابتدا به پروژهی BlazorServer.Entities.csproj مراجعه کرده و موجودیت ثبت اطلاعات تصاویر را تعریف میکنیم:
using System.ComponentModel.DataAnnotations.Schema; namespace BlazorServer.Entities { public class HotelRoomImage { public int Id { get; set; } public string RoomImageUrl { get; set; } [ForeignKey("RoomId")] public virtual HotelRoom HotelRoom { get; set; } public int RoomId { get; set; } } }
namespace BlazorServer.Entities { public class HotelRoom { // ... public virtual ICollection<HotelRoomImage> HotelRoomImages { get; set; } } }
namespace BlazorServer.DataAccess { public class ApplicationDbContext : DbContext { public DbSet<HotelRoomImage> HotelRoomImages { get; set; } // ... } }
dotnet tool update --global dotnet-ef --version 5.0.3 dotnet build dotnet ef migrations --startup-project ../BlazorServer.App/ add Init --context ApplicationDbContext dotnet ef --startup-project ../BlazorServer.App/ database update --context ApplicationDbContext
تعریف مدل UI متناظر با هر تصویر
همانطور که در قسمت 13 نیز عنوان شد، در حین کار با رابط کاربری برنامه، با موجودیتهای بانک اطلاعاتی، به صورت مستقیم کار نخواهیم کرد و بر اساس نیازهای برنامه، یکسری کلاس DTO را تعریف میکنیم. بنابراین به پروژهی BlazorServer.Models مراجعه کرده و DTO متناظر با HotelRoomImage را به صورت زیر اضافه میکنیم:
namespace BlazorServer.Models { public class HotelRoomImageDTO { public int Id { get; set; } public int RoomId { get; set; } public string RoomImageUrl { get; set; } } }
using AutoMapper; using BlazorServer.Entities; namespace BlazorServer.Models.Mappings { public class MappingProfile : Profile { public MappingProfile() { // ... CreateMap<HotelRoomImageDTO, HotelRoomImage>().ReverseMap(); // two-way mapping } } }
تعریف سرویس کار با HotelRoomImage
در اینجا نیز همانند سرویسی که برای انجام عملیات تجاری مرتبط با یک اتاق هتل، در قسمت 13 پیاده سازی کردیم، سرویس دیگری را در پروژهی BlazorServer.Services برای کار با تصاویر اتاقها تهیه میکنیم:
namespace BlazorServer.Services { public interface IHotelRoomImageService { Task<int> CreateHotelRoomImageAsync(HotelRoomImageDTO imageDTO); Task<int> DeleteHotelRoomImageByImageIdAsync(int imageId); Task<int> DeleteHotelRoomImageByRoomIdAsync(int roomId); Task<List<HotelRoomImageDTO>> GetHotelRoomImagesAsync(int roomId); } }
namespace BlazorServer.Services { public class HotelRoomImageService : IHotelRoomImageService { private readonly ApplicationDbContext _dbContext; private readonly IMapper _mapper; private readonly IConfigurationProvider _mapperConfiguration; public HotelRoomImageService(ApplicationDbContext dbContext, IMapper mapper) { _dbContext = dbContext ?? throw new ArgumentNullException(nameof(dbContext)); _mapper = mapper ?? throw new ArgumentNullException(nameof(mapper)); _mapperConfiguration = mapper.ConfigurationProvider; } public async Task<int> CreateHotelRoomImageAsync(HotelRoomImageDTO imageDTO) { var image = _mapper.Map<HotelRoomImage>(imageDTO); await _dbContext.HotelRoomImages.AddAsync(image); return await _dbContext.SaveChangesAsync(); } public async Task<int> DeleteHotelRoomImageByImageIdAsync(int imageId) { var image = await _dbContext.HotelRoomImages.FindAsync(imageId); _dbContext.HotelRoomImages.Remove(image); return await _dbContext.SaveChangesAsync(); } public async Task<int> DeleteHotelRoomImageByRoomIdAsync(int roomId) { var imageList = await _dbContext.HotelRoomImages.Where(x => x.RoomId == roomId).ToListAsync(); _dbContext.HotelRoomImages.RemoveRange(imageList); return await _dbContext.SaveChangesAsync(); } public Task<List<HotelRoomImageDTO>> GetHotelRoomImagesAsync(int roomId) { return _dbContext.HotelRoomImages .Where(x => x.RoomId == roomId) .ProjectTo<HotelRoomImageDTO>(_mapperConfiguration) .ToListAsync(); } } }
namespace BlazorServer.App { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddScoped<IHotelRoomImageService, HotelRoomImageService>(); // ...
تهیه سرویسی برای آپلود فایلهای یک برنامهی Blazor Server به سرور
جهت ساده سازی کار آپلود، در برنامههای Blazor Server، سرویس جدید FileUploadService را به پروژهی BlazorServer.Services اضافه میکنیم:
using Microsoft.AspNetCore.Components.Forms; using System.Threading.Tasks; namespace BlazorServer.Services { public interface IFileUploadService { void DeleteFile(string fileName, string webRootPath, string uploadFolder); Task<string> UploadFileAsync(IBrowserFile inputFile, string webRootPath, string uploadFolder); } }
using Microsoft.AspNetCore.Components.Forms; using System; using System.IO; using System.Threading.Tasks; namespace BlazorServer.Services { public class FileUploadService : IFileUploadService { private const int MaxBufferSize = 0x10000; public void DeleteFile(string fileName, string webRootPath, string uploadFolder) { var path = Path.Combine(webRootPath, uploadFolder, fileName); if (File.Exists(path)) { File.Delete(path); } } public async Task<string> UploadFileAsync(IBrowserFile inputFile, string webRootPath, string uploadFolder) { createUploadDir(webRootPath, uploadFolder); var (fileName, imageFilePath) = getOutputFileInfo(inputFile, webRootPath, uploadFolder); using (var outputFileStream = new FileStream( imageFilePath, FileMode.Create, FileAccess.Write, FileShare.None, MaxBufferSize, useAsync: true)) { using var inputStream = inputFile.OpenReadStream(); await inputStream.CopyToAsync(outputFileStream); } return $"{uploadFolder}/{fileName}"; } private static (string FileName, string FilePath) getOutputFileInfo( IBrowserFile inputFile, string webRootPath, string uploadFolder) { var fileName = Path.GetFileName(inputFile.Name); var imageFilePath = Path.Combine(webRootPath, uploadFolder, fileName); if (File.Exists(imageFilePath)) { var fileNameWithoutExtension = Path.GetFileNameWithoutExtension(fileName); var fileExtension = Path.GetExtension(fileName); fileName = $"{fileNameWithoutExtension}-{Guid.NewGuid()}{fileExtension}"; imageFilePath = Path.Combine(webRootPath, uploadFolder, fileName); } return (fileName, imageFilePath); } private static void createUploadDir(string webRootPath, string uploadFolder) { var folderDirectory = Path.Combine(webRootPath, uploadFolder); if (!Directory.Exists(folderDirectory)) { Directory.CreateDirectory(folderDirectory); } } } }
همچنین برای دسترسی به IBrowserFile در یک سرویس، نیاز است وابستگی زیر را نیز به پروژهی سرویسها اضافه کرد:
<Project Sdk="Microsoft.NET.Sdk"> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Components.Web" Version="5.0.3" /> </ItemGroup> </Project>
namespace BlazorServer.App { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddScoped<IFileUploadService, FileUploadService>(); // ...
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: Blazor-5x-Part-16.zip
Domain Model یا Business Layer
پیاده سازی را از منطق تجاری یا Business Logic آغاز میکنیم. در روش کد نویسی Smart UI، منطق تجاری در Code Behind قرار میگرفت اما در روش لایه بندی، منطق تجاری و روابط بین دادهها در Domain Model طراحی و پیاده سازی میشوند. در مطالب بعدی راجع به Domain Model و الگوهای پیاده سازی آن بیشتر صحبت خواهم کرد اما بصورت خلاصه این لایه یک مدل مفهومی از سیستم میباشد که شامل تمامی موجودیتها و روابط بین آنهاست.
الگوی Domain Model جهت سازماندهی پیچیدگیهای موجود در منطق تجاری و روابط بین موجودیتها طراحی شده است.
شکل زیر مدلی را نشان میدهد که میخواهیم آن را پیاده سازی نماییم. کلاس Product موجودیتی برای ارائه محصولات یک فروشگاه میباشد. کلاس Price جهت تشخیص قیمت محصول، میزان سود و تخفیف محصول و همچنین استراتژیهای تخفیف با توجه به منطق تجاری سیستم میباشد. در این استراتژی همکاران تجاری از مشتریان عادی تفکیک شده اند.
Domain Model را در پروژه SoCPatterns.Layered.Model پیاده سازی میکنیم. بنابراین به این پروژه یک Interface به نام IDiscountStrategy را با کد زیر اضافه نمایید:
public interface IDiscountStrategy { decimal ApplyExtraDiscountsTo(decimal originalSalePrice); }
علت این نوع نامگذاری Interface فوق، انطباق آن با الگوی Strategy Design Pattern میباشد که در مطالب بعدی در مورد این الگو بیشتر صحبت خواهم کرد. استفاده از این الگو نیز به این دلیل بود که این الگو مختص الگوریتم هایی است که در زمان اجرا قابل انتخاب و تغییر خواهند بود.
توجه داشته باشید که معمولا نام Design Pattern انتخاب شده برای پیاده سازی کلاس را بصورت پسوند در انتهای نام کلاس ذکر میکنند تا با یک نگاه، برنامه نویس بتواند الگوی مورد نظر را تشخیص دهد و مجبور به بررسی کد نباشد. البته به دلیل تشابه برخی از الگوها، امکان تشخیص الگو، در پاره ای از موارد وجود ندارد و یا به سختی امکان پذیر است.
الگوی Strategy یک الگوریتم را قادر میسازد تا در داخل یک کلاس کپسوله شود و در زمان اجرا به منظور تغییر رفتار شی، بین رفتارهای مختلف سوئیچ شود.
حال باید دو کلاس به منظور پیاده سازی روال تخفیف ایجاد کنیم. ابتدا کلاسی با نام TradeDiscountStrategy را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public class TradeDiscountStrategy : IDiscountStrategy { public decimal ApplyExtraDiscountsTo(decimal originalSalePrice) { return originalSalePrice * 0.95M; } }
سپس با توجه به الگوی Null Object کلاسی با نام NullDiscountStrategy را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public class NullDiscountStrategy : IDiscountStrategy { public decimal ApplyExtraDiscountsTo(decimal originalSalePrice) { return originalSalePrice; } }
از الگوی Null Object زمانی استفاده میشود که نمیخواهید و یا در برخی مواقع نمیتوانید یک نمونه (Instance) معتبر را برای یک کلاس ایجاد نمایید و همچنین مایل نیستید که مقدار Null را برای یک نمونه از کلاس برگردانید. در مباحث بعدی با جزئیات بیشتری در مورد الگوها صحبت خواهم کرد.
با توجه به استراتژیهای تخفیف کلاس Price را ایجاد کنید. کلاسی با نام Price را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public class Price { private IDiscountStrategy _discountStrategy = new NullDiscountStrategy(); private decimal _rrp; private decimal _sellingPrice; public Price(decimal rrp, decimal sellingPrice) { _rrp = rrp; _sellingPrice = sellingPrice; } public void SetDiscountStrategyTo(IDiscountStrategy discountStrategy) { _discountStrategy = discountStrategy; } public decimal SellingPrice { get { return _discountStrategy.ApplyExtraDiscountsTo(_sellingPrice); } } public decimal Rrp { get { return _rrp; } } public decimal Discount { get { if (Rrp > SellingPrice) return (Rrp - SellingPrice); else return 0; } } public decimal Savings { get{ if (Rrp > SellingPrice) return 1 - (SellingPrice / Rrp); else return 0; } } }
کلاس Price از نوعی Dependency Injection به نام Setter Injection در متد SetDiscountStrategyTo استفاده نموده است که استراتژی تخفیف را برای کالا مشخص مینماید. نوع دیگری از Dependency Injection با نام Constructor Injection وجود دارد که در مباحث بعدی در مورد آن بیشتر صحبت خواهم کرد.
جهت تکمیل لایه Model، کلاس Product را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public class Product { public int Id {get; set;} public string Name { get; set; } public Price Price { get; set; } }
موجودیتهای تجاری ایجاد شدند اما باید روشی اتخاذ نمایید تا لایه Model نسبت به منبع داده ای بصورت مستقل عمل نماید. به سرویسی نیاز دارید که به کلاینتها اجازه بدهد تا با لایه مدل در اتباط باشند و محصولات مورد نظر خود را با توجه به تخفیف اعمال شده برای رابط کاربری برگردانند. برای اینکه کلاینتها قادر باشند تا نوع تخفیف را مشخص نمایند، باید یک نوع شمارشی ایجاد کنید که به عنوان پارامتر ورودی متد سرویس استفاده شود. بنابراین نوع شمارشی CustomerType را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public enum CustomerType { Standard = 0, Trade = 1 }
برای اینکه تشخیص دهیم کدام یک از استراتژیهای تخفیف باید بر روی قیمت محصول اعمال گردد، نیاز داریم کلاسی را ایجاد کنیم تا با توجه به CustomerType تخفیف مورد نظر را اعمال نماید. کلاسی با نام DiscountFactory را با کد زیر ایجاد نمایید:
public static class DiscountFactory { public static IDiscountStrategy GetDiscountStrategyFor (CustomerType customerType) { switch (customerType) { case CustomerType.Trade: return new TradeDiscountStrategy(); default: return new NullDiscountStrategy(); } } }
در طراحی کلاس فوق از الگوی Factory استفاده شده است. این الگو یک کلاس را قادر میسازد تا با توجه به شرایط، یک شی معتبر را از یک کلاس ایجاد نماید. همانند الگوهای قبلی، در مورد این الگو نیز در مباحث بعدی بیشتر صحبت خواهم کرد.
لایهی سرویس با برقراری ارتباط با منبع داده ای، دادههای مورد نیاز خود را بر میگرداند. برای این منظور از الگوی Repository استفاده میکنیم. از آنجایی که لایه Model باید مستقل از منبع داده ای عمل کند و نیازی به شناسایی نوع منبع داده ای ندارد، جهت پیاده سازی الگوی Repository از Interface استفاده میشود. یک Interface به نام IProductRepository را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public interface IProductRepository { IList<Product> FindAll(); }
الگوی Repository به عنوان یک مجموعهی در حافظه (In-Memory Collection) یا انباره ای از موجودیتهای تجاری عمل میکند که نسبت به زیر بنای ساختاری منبع داده ای کاملا مستقل میباشد.
کلاس سرویس باید بتواند استراتژی تخفیف را بر روی مجموعه ای از محصولات اعمال نماید. برای این منظور باید یک Collection سفارشی ایجاد نماییم. اما من ترجیح میدهم از Extension Methods برای اعمال تخفیف بر روی محصولات استفاده کنم. بنابراین کلاسی به نام ProductListExtensionMethods را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public static class ProductListExtensionMethods { public static void Apply(this IList<Product> products, IDiscountStrategy discountStrategy) { foreach (Product p in products) { p.Price.SetDiscountStrategyTo(discountStrategy); } } }
الگوی Separated Interface تضمین میکند که کلاینت از پیاده سازی واقعی کاملا نامطلع میباشد و میتواند برنامه نویس را به سمت Abstraction و Dependency Inversion به جای پیاده سازی واقعی سوق دهد.
حال باید کلاس Service را ایجاد کنیم تا از طریق این کلاس، کلاینت با لایه Model در ارتباط باشد. کلاسی به نام ProductService را با کد زیر به پروژه SoCPatterns.Layered.Model اضافه کنید:
public class ProductService { private IProductRepository _productRepository; public ProductService(IProductRepository productRepository) { _productRepository = productRepository; } public IList<Product> GetAllProductsFor(CustomerType customerType) { IDiscountStrategy discountStrategy = DiscountFactory.GetDiscountStrategyFor(customerType); IList<Product> products = _productRepository.FindAll(); products.Apply(discountStrategy); return products; } }
در اینجا کدنویسی منطق تجاری در Domain Model به پایان رسیده است. همانطور که گفته شد، لایهی Business یا همان Domain Model به هیچ منبع داده ای خاصی وابسته نیست و به جای پیاده سازی کدهای منبع داده ای، از Interfaceها به منظور برقراری ارتباط با پایگاه داده استفاده شده است. پیاده سازی کدهای منبع داده ای را به لایهی Repository واگذار نمودیم که در بخشهای بعدی نحوه پیاده سازی آن را مشاهده خواهید کرد. این امر موجب میشود تا لایه Model درگیر پیچیدگیها و کد نویسیهای منبع داده ای نشود و بتواند به صورت مستقل و فارغ از بخشهای مختلف برنامه تست شود. لایه بعدی که میخواهیم کد نویسی آن را آغاز کنیم، لایهی Service میباشد.
در کد نویسیهای فوق از الگوهای طراحی (Design Patterns) متعددی استفاده شده است که به صورت مختصر در مورد آنها صحبت کردم. اصلا جای نگرانی نیست، چون در مباحث بعدی به صورت مفصل در مورد آنها صحبت خواهم کرد. در ضمن، ممکن است روال یادگیری و آموزش بسیار نامفهوم باشد که برای فهم بیشتر موضوع، باید کدها را بصورت کامل تست نموده و مثالهایی را پیاده سازی نمایید.