چه نوع اپلیکیشنهای را میتوان با Node.js توسعه داد؟
- سرور WebSocket جهت توسعهی اپلیکیشنهای بلادرنگ
- فایل آپلودر سریع در سمت کلاینت
- Ad Server
- و ...
var contents = fs.readFileSync('filePath'); console.log(content); console.log('Doing something else');
fs.readFile('filePath', function (err, contents) { console.log(contents); }); console.log('Doing something else');
برای شروع به کار با Node.js میتوانید با مراجعه به وبسایت رسمی آن، آنرا دانلود و بر روی سیستم خود نصب کنید. بعد از نصب Node میتوانیم از طریق command line وارد shell آن شوید و دستورات جاوا اسکریپتی خود را اجرا نمائید:
احتمالاً به این نوع استفادهی از Node.js که به REPL معروف است، نیازی نداشته باشید. در واقع هدف بررسی نصب بودن رانتایم بر روی سیستم است. با استفاده از فرمان node نیز میتوان یک فایل جاوا اسکریپتی را اجرا کرد. برای اینکار یک فایل با نام test.js را با محتویات زیر درون VS Code ایجاد کنید:
سپس دستور node test.js را وارد کنید:
همانطور که مشاهده میکنید نتیجهی فایل عنوان شده، در خروجی نمایش داده شده است. در حالت کلی تمام کاری که نود انجام میدهد، ارائه یک Execution engine برای جاوا اسکریپت میباشد.
استفاده از Node.js در ویژوال استودیو
برای کار با Node.js درون ویژوال استودیو باید ابتدا افزونهی Node.js Tools را برای ویژوال استودیو نصب کنید. بعد از نصب این افزونه، تمپلیت Node.js در زمان ایجاد یک پروژه برای شما نمایش داده خواهد شد:
برای شروع، تمپلیت Blank Node.js Console Application را انتخاب کرده و بر روی OK کلیک کنید. با اینکار یک پروژه با ساختار زیر برایمان ایجاد خواهد شد:
همانطور که ملاحظه میکنید، یک فایل با نام app.js درون تمپلیت ایجاد شده، موجود است. app.js در واقع نقطهی شروع برنامهمان خواهد بود. همچنین دو فایل دیگر نیز با نامهای README.md، جهت افزودن توضیحات و یک فایل با نام package.json، جهت مدیریت وابستگیهای برنامه به پروژه اضافه شدهاند. اکنون میتوانیم شروع به توسعهی برنامهی خود درون ویژوال استودیو کنیم. همچنین میتوانیم از قابلیتهای debugging ویژوال استودیو نیز بهره ببریم:
اگر مسیر پروژهی ایجاد شدهی فوق را درون windows explorer باز کنید خواهید دید که ساختار آن شبیه به یک پروژهی Node.js میباشد. با این تفاوت که دو آیتم دیگر همانند دیگر پروژههای ویژوال استودیو نیز به آن اضافه شده است که طبیعتاً میتوانید در حین کار با سورس کنترل، از انتشار آنها صرفنظر کنید.
لازم به ذکر است پروژهی ایجاد شدهی فوق را نیز میتوانید همانند حالت عادی، از طریق command line و همانند پروژههای Node.js اجرا کنید:
node app.js
در واقع از ویژوال استدیو میتوانیم به عنوان یک ابزار برای دیباگ پروژههای Node.js استفاده کنیم. لازم به ذکر است، Visual Studio Code نیز امکان دیباگ اپلیکیشنهای Node.js را در اختیارمان قرار میدهد. در نتیجه در مواقعیکه نسخهی کامل ویژوال استودیو در دسترس نیست نیز میتوانیم از VS Code برای دیباگ برنامههایمان استفاده کنیم:
- Create Database
- Delete Database
- Migrate Database
- Seed Database
services.AddParbad() .ConfigureDatabase(builder => { // Choose your database provider (SQL Server, MySql, Sqlite, etc.) builder.Use.... }) .ConfigureDatabaseInitializer(builder => { builder.UseInitializer(async context => { await context.Database.EnsureDeletedAsync(); // OR await context.Database.EnsureCreatedAsync(); // OR await context.Database.MigrateAsync(); }); });
services.AddParbad() .ConfigureDatabase(builder => { // Choose your Entity Framework provider (SQL Server, MySql, Sqlite, etc.) builder.Use.... }) .ConfigureDatabaseInitializer(builder => { builder.CreateDatabase(); // OR builder.DeleteAndCreateDatabase(); // OR builder.CreateAndMigrateDatabase(); });
services.AddParbad() .ConfigureDatabase(builder => { // SQL Server builder.UseSqlServer("Connection String", options => options.UseParbadMigrations()); }) .ConfigureDatabaseInitializer(builder => { builder.CreateAndMigrateDatabase(); });
builder.UseSqlServer("Connection String", options => options.MigrationsAssembly("Parbad"));
نمونه مثالها را همچنین میتوانید در صفحه GitHub پروژه مشاهده کنید.
Autofac به دنبال صاحبان جدید
StringBuilder
بهترین روش برای تولید و دستکاری یک رشته (string) طولانی و یا دستکاری متناوب و تکراری یک رشته استفاده از کلاس StringBuilder است. این کلاس در فضای نام System.Text قرار داره. شی String در داتنتفریمورک تغییرناپذیره (immutable)، بدین معنی که پس از ایجاد نمیتوان محتوای اونو تغییر داد. برای مثال اگر شما بخواین محتوای یک رشته رو با اتصال به رشتهای دیگه تغییر بدین، اجازه اینکار را به شما داده نمیشه. درعوض بهصورت خودکار رشتهای جدید در حافظه ایجاد میشه و محتوای دو رشته موجود پس از اتصال به هم درون اون قرار میگیره. این کار درصورتیکه تعداد عملیات مشابه زیاد باشه میتونه تاثیر منفی بر کارایی و حافظه خالی در دسترس برنامه بگذاره.
کلاس StringBuilder با استفاده از آرایهای از کاراکترها، راهحل مناسب و بهینهای رو برای این مشکل فراهم کرده. این کلاس در زمان اجرا به شما اجازه میده تا بدون ایجاد نمونههای جدید از کلاس String، محتوای یک رشته رو تغییر بدین. شما میتونید نمونهای از این کلاس رو بهصورت خالی و یا با یک رشته اولیه ایجاد کنید، سپس با استفاده از متدهای متنوع موجود، محتوای رشته رو با استفاده از انواع داده مختلف و بهصورت دلخواه دستکاری کنید. همچنین با استفاده از متد معروف ()ToString این کلاس میتونید در هر لحظه دلخواه رشته تولیدی رو بدست بیارین. دو پراپرتی مهم کلاس StringBuilder رفتارش رو درهنگام افزودن دادههای جدید کنترل میکنن:
Capacity , Length
پراپرتی Capacity اندازه بافر کلاس StringBuilder را تعیین میکنه و Length طول رشته جاری موجود در این بافر رو نمایش میده. اگر پس از افزودن داده جدید، طول رشته از اندازه بافر موجود بیشتر بشه، StringBuilder باید یه بافر جدید با اندازهای مناسب ایجاد کنه تا رشته جدید رو بتونه تو خودش نگه داره. اندازه این بافر جدید بهصورت پیشفرض دو برابر اندازه بافر قبلی درنظر گرفته میشه. بعد تمام رشته قبلی رو تو این بافر جدید کپی میکنه.
از برنامه ساده زیر میتونین برای بررسی این مسئله استفاده کنین:
using System.IO; using System.Text; class Program { static void Main() { using (var writer = new StreamWriter("data.txt")) { var builder = new StringBuilder(); for (var i = 0; i <= 256; i++) { writer.Write(builder.Capacity); writer.Write(","); writer.Write(builder.Length); writer.WriteLine(); builder.Append('1'); // <-- Add one character } } } }
دقت کنین که برای افزودن یک کاراکتر استفاده از دستور Append با نوع داده char (همونطور که در بالا استفاده شده) بازدهی بهتری نسبت به استفاده از نوع داده string (با یک کاراکتر) داره. خروجی کد فوق به صورت زیره:
16, 0 16, 1 16, 2 ... 16,14 16,15 16,16 32,17 ...
استفاده نامناسب و بیدقت از این کلاس میتونه منجر به بازسازیهای متناوب این بافر شده که درنهایت فواید کلاس StringBuilder رو تحت تاثیر قرار میده. درهنگام کار با کلاس StringBuilder اگر از طول رشته موردنظر و یا حد بالایی برای Capacity آن آگاهی حتی نسبی دارین، میتونید با مقداردهی مناسب این پراپرتی از این مشکل پرهیز کنید.
نکته: مقدار پیشفرض پراپرتی Capacity برابر 16 است.
هنگام مقداردهی پراپرتیهای Capacity یا Length به موارد زیر توجه داشته باشید:
- مقداردهی Capacity به میزانی کمتر از طول رشته جاری (پراپرتی Length)، منجر به خطای زیر میشه:
System.ArgumentOutOfRangeException
خطای مشابهی هنگام مقداردهی پراپرتی Capacityبه بیش از مقدار پراپرتی MaxCapacity رخ میدهه.البته این مورد تنها درصورتیکه بخواین اونو به بیش از حدود 2 گیگابایت (Int32.MaxValue) مقداردهی کنید پیش میاد!
- اگر پراپرتی Length را به مقداری کمتر از طول رشته جاری تنظیم کنید، رشته به اندازه طول تنظیمی کوتاه (truncate) میشه.
- اگر مقدار پراپرتی Length را به میزانی بیشتر از طول رشته جاری تنظیم کنید، فضای خالی موجود در بافر با space پر میشه.
- تنظیم مقدار Length بیشتر از Capacity، منجر به مقداردهی خودکار پراپرتی Capacity به مقدار جدید تنظیم شده برای Length میشه.
در ادامه به یک مثال برای مقایسه کارایی تولید یک رشته طولانی با استفاده از این کلاس میپردازیم. تو این مثال از دو روش برای تولید رشتههای طولانی استفاده میشه. روش اول که همون روش اتصال رشتهها (Concat) به هم هستش و روش دوم هم که استفاده از کلاس StringBuilder است. در قطعه کد زیر کلاس مربوط به عملیات تست رو مشاهده میکنین:
namespace StringBuilderTest { internal class SbTest1 { internal Action<string> WriteLog; internal int Iterations { get; set; } internal string TestString { get; set; } internal SbTest1(int iterations, string testString, Action<string> writeLog) { Iterations = iterations; TestString = testString; WriteLog = writeLog; } internal void StartTest() { var watch = new Stopwatch(); //StringBuilder watch.Start(); var sbTestResult = SbTest(); watch.Stop(); WriteLog(string.Format("StringBuilder time: {0}", watch.ElapsedMilliseconds)); //Concat watch.Start(); var concatTestResult = ConcatTest(); watch.Stop(); WriteLog(string.Format("ConcatTest time: {0}", watch.ElapsedMilliseconds)); WriteLog(string.Format("Results are{0} the same", sbTestResult == concatTestResult ? string.Empty : " NOT")); } private string SbTest() { var sb = new StringBuilder(TestString); for (var x = 0; x < Iterations; x++) { sb.Append(TestString); } return sb.ToString(); } private string ConcatTest() { string concat = TestString; for (var x = 0; x < Iterations; x++) { concat += TestString; } return concat; } } }
دو روش بحثشده در کلاس مورد استفاده قرار گرفته و مدت زمان اجرای هر کدوم از عملیاتها به خروجی فرستاده میشه. برای استفاده از این کلاس هم میشه از کد زیر در یک برنامه کنسول استفاده کرد:
do { Console.Write("Iteration: "); var iterations = Convert.ToInt32(Console.ReadLine()); Console.Write("Test String: "); var testString = Console.ReadLine(); var test1 = new SbTest1(iterations, testString, Console.WriteLine); test1.StartTest(); Console.WriteLine("----------------------------------------------------------------"); } while (Console.ReadKey(true).Key == ConsoleKey.C); // C = continue
برای نمونه خروجی زیر در لپتاپ من (Corei7 2630QM) بدست اومد:
تنظیم خاصیت Capacity به یک مقدار مناسب میتونه تو کارایی تاثیرات زیادی بگذاره. مثلا در مورد مثال فوق میشه یه متد دیگه برای آزمایش تاثیر این مقداردهی به صورت زیر به کلاس برناممون اضافه کنیم:
private string SbCapacityTest() { var sb = new StringBuilder(TestString) { Capacity = TestString.Length * Iterations }; for (var x = 0; x < Iterations; x++) { sb.Append(TestString); } return sb.ToString(); }
تو این متد قبل از ورود به حلقه مقدار خاصیت Capacity به میزان موردنظر تنظیم شده و نتیجه بدست اومده:
مشاهده میشه که روش concat خیلی کنده (دقت کنین که طول رشته اولیه هم بیشتر شده) و برای ادامه کار مقایسه اون رو کامنت کردم و نتایج زیر بدست اومد:
میبینین که استفاده مناسب از مقداردهی به خاصیت Capacity میتونه تا حدود 300 درصد سرعت برنامه ما رو افزایش بده. البته همیشه اینطوری نخواهد بود. ما در این مثال مقدار دقیق طول رشته نهایی رو میدونستیم که باعث میشه عملیات افزایش بافر کلاس StringBuilder هیچوقت اتفاق نیفته. این امر در واقعیت کمتر پیش میاد.
مقاله موجود در سایت dotnetperls شکل زیر رو به عنوان نتیجه تست بازدهی ارائه میده:
- در مواقعی که عملیاتی همچون مثال بالا طولانی و حجیم ندارین بهتره که از این کلاس استفاده نکنین چون عملیاتهای داخلی این کلاس در عملیات کوچک و سبک (مثل ابتدای نمودار فوق) موجب کندی عملیات میشه. همچنین استفاده از اون نیاز به کدنویسی بیشتری داره.
- این کلاس فشار کمتری به حافظه سیستم وارد میکنه. درمقابل استفاده از روش concat موجب اشغال بیش از حد حافظه میشه که خودش باعث اجرای بیشتر و متناوبتر GC میشه که در نهایت کارایی سیستم رو کاهش میده.
- استفاده از این کلاس برای عملیات Replace (و یا عملیات مشابه) در حلقهها جهت کار با رشتههای طولانی و یا تعداد زیادی رشته میتونه بسیار سریعتر و بهتر عمل کنه چون این کلاس برخلاف کلاس string اشیای جدید تولید نمیکنه.
- یه اشتباه بزرگ در استفاده از این کلاس استفاده از "+" برای اتصال رشتههای درون StringBuilder هست. هرگز از این کارها نکنین. (فکر کنم واضحه که چرا)
برای رفع این مشکلات، از روشهای توسعهی به همراه ابزارهای یکپارچگی مداوم استفاده میشود. برای نمونه، AppVeyor یکی از سرویسهای ابری یکپارچگی مداوم (Continuous Integration و یا به اختصار CI) است. به کمک آن میتوان یک image از ویندوز سرور را به همراه ابزارهای build، آزمایش و توزیع برنامههای NET. در اختیار داشت. این سرویس، مخزن کد شما را مونیتور کرده و هر زمانیکه تغییری را در آن ایجاد کردید، آنها را به صورت خودکار build و در صورت موفقیت آمیز بودن این عملیات، بستهی نیوگت متناظری را به سایت nuget.org ارسال میکند. بنابراین پس از یکپارچه کردن مخزن کد خود با این نوع سرویسهای یکپارچگی مداوم، دیگر حتی نیازی به build دستی آن نیز نخواهید داشت. همینقدر که کدی را به مخزن کد تحت نظر، commit کنید، مابقی مراحل آن خودکار است.
به همین جهت در این مطلب قصد داریم نحوهی اتصال یک مخزن کد GitHub را به سرویس یکپارچگی مداوم AppVeyor، جهت تولید خودکار بستههای Nuget، بررسی کنیم.
معرفی سرویس ابری AppVeyor
AppVeyor یک راه حل یکپارچگی مداوم چند سکویی است که استفادهی از آن برای پروژههای سورس باز رایگان است و سازگاری فوق العادهای را با محصولات مایکروسافت دارد. برای ورود به آن میتوان از اکانتهای GitHub ،BitBucket و VSTS (Visual Studio Team Services) استفاده کرد.
گردش کاری متداول یکپارچگی مداوم AppVeyor به این صورت است:
الف) با اکانت GitHub خود به آن وارد شوید.
ب) یک مخزن کد GitHub خود را به آن Import کنید.
ج) به مخزن کد GitHub خود یک فایل yml. تنظیمات مخصوص AppVeyor را اضافه کنید.
د) نظارهگر Build و توزیع خودکار پروژهی خود باشید.
ایجاد اکانت و اتصال به مخزن کد GitHub
در ابتدا به صفحهی لاگین آن مراجعه کنید. در اینجا جهت سهولت کار با GitHub و مخازن کد آن، گزینهی GitHub را انتخاب کرده و توسط آن به سیستم وارد شوید:
پس از ورود موفق، گزینهی new project را انتخاب کنید:
در ادامه مخزن کد GitHub و نوع عمومی آنرا انتخاب میکنیم تا AppVeyor بتواند پروژههای آنرا Import کند و همچنین به آنها web hookهایی را اضافه کند تا با اعمال تغییراتی در سمت GitHub، کار اطلاع رسانی آنها به AppVeyor به صورت خودکار صورت گیرد:
پس از آن لیست مخزنهای کد شما در همینجا ارائه میشود تا بتوانید یک یا چند مورد را انتخاب کنید:
انجام تنظیمات عمومی مخزن کد
در صفحهی بعدی، برگهی settings و سپس از منوی کنار صفحهی آن، گزینهی General را انتخاب کنید:
در اینجا اگر پروژهی شما از نوع NET Core. است، گزینهی NET Core .csproj patching. را انتخاب نمائید:
سپس در پایین صفحه بر روی دکمهی Save کلیک کنید.
انتخاب و تنظیم محیط Build
در ادامه در برگهی settings و سپس از منوی کنار صفحهی آن، گزینهی Environment را انتخاب کنید:
در این صفحه، worker image را بر روی VS 2017 قرار دهید و همچنین در قسمت Cached directories and files، مسیر C:\Users\appveyor\.dnx را جهت کش کردن عملیات Build و بالا بردن سرعت آن، مقدار دهی کنید. سپس در پایین صفحه بر روی دکمهی Save کلیک نمائید.
اکنون بر روی گزینهی Build در منوی سمت چپ صفحه کلیک کنید. در اینجا سه حالت msbuild ،script و off را میتوان انتخاب کرد.
- در حالت msbuild، که سادهترین حالت ممکن است، فایل sln. مخزن کد، یافت شده و بر اساس آن به صورت خودکار تمام پروژههای این solution یکی پس از دیگری build خواهند شد. این مورد برای برنامههای Full .NET Framework شاید گزینهی مناسبی باشد.
- حالت script برای پروژههای NET Core. مناسبتر است و در این حالت میتوان کنترل بیشتری را بر روی build داشت. به علاوه این روش بر روی لینوکس هم کار میکند؛ زیرا در آنجا دسترسی به msbuild نداریم.
- حالت off به معنای خاموش کردن عملیات build است.
در اینجا گزینهی cmd را جهت ورود build script انتخاب میکنیم:
سپس دستورات ذیل را جهت ورود به پوشهی پروژهی کتابخانه (جائیکه فایل csproj آن قرار دارد)، بازیابی وابستگیهای پروژه و سپس تولید بستهی نیوگتی از آن، وارد میکنیم:
cd ./src/DNTPersianUtils.Core dotnet restore dotnet pack -c release cd ../..
ذکر ../.. cd در انتهای این دستورات ضروری است. در غیر اینصورت cd بعدی در تنظیماتی دیگر، داخل همین پوشه انجام میشود.
تنظیم اجرای خودکار آزمونهای واحد
در همین صفحه، گزینههای settings -> tests -> script -> cmd را انتخاب و سپس دستورات زیر را وارد کرده و آنرا ذخیره کنید:
cd ./src/DNTPersianUtils.Core.Tests dotnet restore dotnet test cd ../..
تنظیم اطلاع رسانی خودکار از اجرای عملیات
در برگهی settings -> notifications مطابق تنظیمات فوق میتوان نوع email را جهت اطلاع رسانی شکست انجام عملیات یکپارچگی مداوم، انتخاب کرد.
آزمایش Build خودکار
برای آزمایش تنظیماتی که انجام دادیم، به برگهی latest build مراجعه کرده و بر روی دکمهی new build کلیک کنید تا اسکریپتهای build و test فوق اجرا شوند. بدیهی است اجرای بعدی این اسکریپتها خودکار بوده و به ازای هر commit به GitHub، بدون نیاز به مراجعهی مستقیم به appveyor صورت میگیرند.
اضافه کردن نماد AppVeyor به پروژه
در تنظیمات برگهی Settings، گزینهی AppVeyor badge نیز در منوی سمت چپ صفحه، وجود دارد:
در اینجا همان کدهای mark down آنرا انتخاب کرده و به ابتدای فایل readme پروژهی خود اضافه کنید. برای نمونه نماد فعلی (تصویر فوق)، build failing را نمایش میدهد؛ چون سه آزمون واحد آن مشکل دارند و باید اصلاح شوند.
پس از رفع مشکلات پروژه و commit آنها، build و اجرای خودکار آزمونهای واحد آن توسط AppVeyor صورت گرفته و اینبار این نماد به صورت زیر تغییر میکند:
ارسال خودکار بستهی نیوگت تولید شده به سایت nuget.org
برای ارسال خودکار حاصل Build، به سایت نیوگت، نیاز است یک API Key داشته باشیم. به همین جهت به صفحهی مخصوص آن در سایت nuget پس از ورود به سایت آن، مراجعه کرده و یک کلید API جدید را صرفا برای این پروژه تولید کنید (در قسمت Available Packages بستهی پیشینی را که دستی آپلود کرده بودید انتخاب کنید).
در اینجا API Key را ذکر خواهیم کرد. سپس در پایین صفحه بر روی دکمهی Save کلیک کنید.
همچنین نیاز است مشخص کنیم که بستههای nupkg تولید شده در چه مسیری قرار دارند. به همین جهت در قسمت settings -> artifacts مسیر پوشهی bin نهایی را ذکر میکنیم:
این مورد را نیز با کلیک بر روی دکمهی Save ذخیره کنید.
اکنون اگر نگارش جدیدی را به GitHub ارسال کنیم (تغییر VersionPrefix در فایل csproj و سپس commit آن)، پس از Build پروژه، بستهی نیوگت آن نیز به صورت خودکار تولید شده و به سایت nuget.org ارسال میشود. لاگ آنرا در پایین صفحهی برگهی latest build میتوانید مشاهده کنید.
ساده سازی مراحل تنظیمات AppVeyor
در صفحهی settings، در منوی سمت چپ آن، گزینهی export YAML نیز وجود دارد. در اینجا میتوان تمام تنظیمات انجام شدهی فوق را با فرمت yml. دریافت کرد و سپس این فایل را به ریشهی مخزن کد خود افزود. با وجود این فایل، دیگر نیازی به طی کردن دستی هیچکدام از مراحل فوق نیست.
برای نمونه فایل appveyor.yml نهایی مطابق با توضیحات این مطلب، چنین محتوایی را دارد:
version: 1.0.{build} image: Visual Studio 2017 dotnet_csproj: patch: true file: '**\*.csproj' version: '{version}' package_version: '{version}' assembly_version: '{version}' file_version: '{version}' informational_version: '{version}' cache: C:\Users\appveyor\.dnx build_script: - cmd: >- cd ./src/DNTPersianUtils.Core dotnet restore dotnet pack -c release cd ../.. test_script: - cmd: >- cd ./src/DNTPersianUtils.Core.Tests dotnet restore dotnet test cd ../.. artifacts: - path: ./src/DNTPersianUtils.Core/bin/release/*.nupkg name: NuGet deploy: - provider: NuGet api_key: secure: xyz skip_symbols: true notifications: - provider: Email to: - me@yahoo.com on_build_success: false on_build_failure: true on_build_status_changed: true
یک نکته: api_key ذکر شدهی در اینجا در قسمت secure، رمزنگاری شدهاست. برای تولید آن میتوانید از مسیر https://ci.appveyor.com/tools/encrypt استفاده کنید. به این صورت مشکلی با عمومی کردن فایل appveyor.yml خود در GitHub نخواهید داشت.
PM> Install-Package LightInject
PM> Install-Package LightInject.Source
public class PersonModel { public int Id { get; set; } public string Name { get; set; } public string Family { get; set; } public DateTime Birth { get; set; } } public interface IRepository<T> where T:class { void Insert(T entity); IEnumerable<T> FindAll(); } public interface IPersonRepository:IRepository<PersonModel> { } public class PersonRepository:IPersonRepository { public void Insert(PersonModel entity) { throw new NotImplementedException(); } public IEnumerable<PersonModel> FindAll() { throw new NotImplementedException(); } } public interface IPersonService { void Insert(PersonModel entity); IEnumerable<PersonModel> FindAll(); } public class PersonService:IPersonService { private readonly IPersonRepository _personRepository; public PersonService(IPersonRepository personRepository) { _personRepository = personRepository; } public void Insert(PersonModel entity) { _personRepository.Insert(entity); } public IEnumerable<PersonModel> FindAll() { return _personRepository.FindAll(); } }
public partial class Form1 : Form { private readonly IPersonService _personService; public Form1(IPersonService personService) { _personService = personService; InitializeComponent(); } }
static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); var container = new ServiceContainer(); container.Register<IPersonService, PersonService>(); container.Register<IPersonRepository, PersonRepository>(); Application.Run(new Form1(container.GetInstance<IPersonService>())); }
public class WorkerModel:PersonModel { public ManagerModel Manager { get; set; } } public class ManagerModel:PersonModel { public IEnumerable<WorkerModel> Workers { get; set; } } public class WorkerRepository:IPersonRepository { public void Insert(PersonModel entity) { throw new NotImplementedException(); } public IEnumerable<PersonModel> FindAll() { throw new NotImplementedException(); } } public class ManagerRepository:IPersonRepository { public void Insert(PersonModel entity) { throw new NotImplementedException(); } public IEnumerable<PersonModel> FindAll() { throw new NotImplementedException(); } } public class WorkerService:IPersonService { private readonly IPersonRepository _personRepository; public WorkerService(IPersonRepository personRepository) { _personRepository = personRepository; } public void Insert(PersonModel entity) { var worker = entity as WorkerModel; _personRepository.Insert(worker); } public IEnumerable<PersonModel> FindAll() { return _personRepository.FindAll(); } } public class ManagerService:IPersonService { private readonly IPersonRepository _personRepository; public ManagerService(IPersonRepository personRepository) { _personRepository = personRepository; } public void Insert(PersonModel entity) { var manager = entity as ManagerModel; _personRepository.Insert(manager); } public IEnumerable<PersonModel> FindAll() { return _personRepository.FindAll(); } }
... var container = new ServiceContainer(); container.Register<IPersonService, PersonService>(); container.Register<IPersonService, WorkerService>(); container.Register<IPersonRepository, PersonRepository>(); container.Register<IPersonRepository, WorkerRepository>(); Application.Run(new Form1(container.GetInstance<IPersonService>()));
... container.Register<IPersonService, PersonService>("PersonService"); container.Register<IPersonService, WorkerService>(); container.Register<IPersonRepository, PersonRepository>(); container.Register<IPersonRepository, WorkerRepository>(); Application.Run(new Form1(container.GetInstance<IPersonService>("PersonService")));
container.Register<IPersonService, PersonService>("PersonService"); Application.Run(new Form1(container.GetInstance<IPersonService>()));
container.Register<IPersonService, PersonService>(); container.Register<IPersonService, WorkerService>("WorkerService"); var personList = container.GetInstance<IEnumerable<IPersonService>>();
container.Register<IPersonService, PersonService>(); container.Register<IPersonService, WorkerService>("WorkerService"); var personList = container.GetAllInstances<IPersonService>();
- Array
- ICollection<T>
- IList<T>
- IReadOnlyCollection<T>
- IReadOnlyList<T>
container.RegisterInstance<string>("SomeValue"); var value = container.GetInstance<string>();
container.RegisterInstance<string>("SomeValue","String1"); container.RegisterInstance<string>("OtherValue","String2"); var value = container.GetInstance<string>("String2");
بررسی روش ارتقاء به NET Core 1.1.
(اسکریپت را در فایل متنی (برای مثال scriptFile ) قرار دهید سپس با دستور chmod u+rx scriptFile قابلیت اجرایی بهش بدید و اجراش کنید sudo ./scriptFile)
در مرحله بعد میتوانید پکیجها را خودتان بصورت دستی دانلود و نصب کنید از این آدرس
دقت شود که مطابق مقالات این سایت نسخه Current را نصب کنید و از LTS صرفنظر کنید تا به روزتر بمانید. ولی اگر قصد انجام پروژه جدی ای دارید وارون این گفته انتخاب کنید.
برای سهولت نصب و استفاده از آپدیتها میتوانید از ترمینال استفاده کنید. کارها رو خودکار پیش ببرید.
راهنمای نصب از طریق ترمینال برای لینوکس های اوبونتو و مینت ، دبیان، ردهت، فدورا، سنت اُ اِس و اُراکل، اُپن زوزه در اینجا
قبل از اینکه این موضوع را بررسی کنیم باید با دستور Truncate و Delete آشنا شویم.
DELETE FROM table_name WHERE some_column=some_value
DELETE FROM Customers WHERE Country=’USA’ GO
اما نکته مهمی که دستور Delete دارد این است کار این دستور به شکل Transactional میباشد. یعنی یا کلیه رکوردهایی که Country آنها USA است حذف میشود و یا هیچکدام از آنها. پس اگر شما 200000 رکورد داشته باشید که در این شرط صدق کند اگر وسط کار Delete (البته اگر عملیات حذف طولانی باشد) منصرف شوید میتوانید با Cancel کردن این دستور عملیات Rollback Transaction را به خودکار توسط SQL Server داشته باشید. در صورتیکه عملیات Cancel را انجام دهید SQL Server از Log File برای بازگرداندن مقادیر حذف شده استفاده خواهد کرد.
شکل کلی استفاده از این دستور به صورت زیر میباشد.
TRUNCATE TABLE table_name GO
TRUNCATE TABLE Customers GO
2- دستور Truncate Table در Log File آدرس Page و مقدار فضای آزاد شده (کمترین میزان Log) را مینویسد اما در صورتیکه دستور Delete در Log هر رکوردی را که
قرار است حذف شود را در Log File ثبت مینماید.
3- دستور Truncate Table باعث میشود که Pageهای متعلق به جدول deallocate شوند. deallocate شدن Pageها این معنی را میدهد که رکوردهای موجود در جدول واقعاً حذف نشوند بلکه Extentهای مربوط به آن Pageها علامت Empty خورده تا دفعات بعد مورد استفاده قرار گیرند اما دستور Delete به طور فیزیکی محتوای Pageها مربوط به جدول را خالی میکند.
نکته : پس از Truncate شدن رکوردها امکان بازگشت آنها وجود ندارد.
4- در صورتیکه جدول شما دارای ایندکس باشد. دستور Truncate Table آزاد کردن فضای مربوط به ایندکس را در یک مرحله انجام میدهد(مطابق بند 3) همچنین Log مربوط به این حذف به شکل حداقل (مطابق بند 2) در Log File ثبت میشود. اما دستور Delete هر رکوردی را که از ایندکس حذف میکند در Log File ثبت میکند.
5- Trigger مربوط به دستور Delete به هیچ عنوان هنگام اجرای دستور Truncate Table فعال نمیشود. در صورتیکه با اجرای دستور Delete تریگر آن فعال خواهد شد.
6- در صورتیکه جدول شما دارایRelation) Reference) باشد امکان استفاده از دستور Truncate Table وجود ندارد. لازم به ذکر است حتی اگر Reference را غیر فعال کنید
باز هم امکان استفاده از دستور Truncate Table وجود نخواهد داشت و تلاش برای اجرای دستور Truncate Table باعث نمایش خطای زیر خواهد شد.
در صورتیکه در دستور Delete امکان حذف رکوردها به ازای جداولی که دارای Relation هستند وجود دارد. فقط باید به این نکته توجه کنید که ترتیب حذف رکوردها از جداول Master و Detail را رعایت کنید.
7- دستور Truncate Table مقدار Identity را Reset کرده و آن را به Seed (هسته/مقدار اولیه) بر میگرداند. در صورتیکه دستور Delete تاثیری بر روی مقدار Identity ندارد
8- دستور Truncate Table تنها توسط کاربرانی قابل اجرا است که نقش DB_Owner و یا SysAdmin را داشته باشند در صورتیکه دستور Delete توسط هر کاربری که مجوز Delete بر روی جدول را داشته باشد قابل اجرا میباشد.
9- پس از اجرای دستور Truncate Table تعداد رکوردهای حذف شده نمایش داده نمیشود. در صورتیکه هنگام اجرای دستور Delete تعداد رکوردهای حذف شده نمایش داده میشود.