با پیشرفت HTML 5 و پدید آمدن چارچوبهای مختلف JavaScript توسعهی نرم افزارهای تک صفحه ای تحت وب (Single Page Applications) محبوب شده است.
اخیرا مطالب خوبی در رابطه با AngularJS در وبسایت جاری منتشر شده است. KnockoutJS توسط Microsoft معرفی شد و در قالب پیشفرض پروژههای SPA قرار گرفت ، بنابراین احتمالا این سوال برای افرادی مطرح شده است که تفاوت بین KnockoutJS و AngularJS چیست ؟
می توان پاسخ داد این مقایسه ممکن نیست.
KnockoutJS : یک پیاده سازی مستقل JavaScript از الگوی MVVM با امکانات Databinding میباشد. Knokcout یک کتابخانهی Databinding است نه یک کتاب خانهی SPA
AngularJS : طبق معرفی در این مطلب AngularJS فریم ورکی متن باز و نوشته شده به زبان جاوا اسکریپت است. هدف از به وجود آمدن این فریم ورک، توسعه هر چه سادهتر SPAها با الگوی طراحی MVC و تست پذیری هر چه آسانتر آنها است. این فریم ورک توسط یکی از محققان Google در سال 2009 به وجود آمد. بعدها این فریم ورک تحت مجوز MIT به صورت متن باز در آمد و اکنون گوگل آن را حمایت میکند و توسط هزاران توسعه دهنده در سرتاسر دنیا، توسعه داده میشود.
بنابراین شاید بهتر باشد ذکر شود AngularJS یک Presentation Framework مخصوص برنامههای وب تک صفحه ای میباشد در حالی که KnockoutJS کتاب خانه ای با تمرکز بر Databinding میباشد ، بنابراین مقایسهی اینها چندان صحیح نیست.
اگر قصد بر بررسی گزینههای دیگر در کنار Angular باشد ، میتوان از Durandal نام برد. Durandal یک چارچوب SPA میباشد ، این چارچوب بر فراز jQuery ، RequireJS و Knockout توسعه پیدا کرده است. (سابقا برای routing از SammyJS استفاده میکرد که در نسخههای اخیر از موتور خودش استفاده میکند.)
Durandal از Knockout جهت Databinding و از RequireJS برای مدیریت وابستگیها استفاده میکند.
Angular همهی امکانات بالا را مستقل پیاده سازی کرده و حتی نیازی به jQuery ندارد. اگر jQuery وجود داشته باشد Angular از آن استفاده میکند در غیر این صورت از jQuery Lite یا jqLite استفاده میکند. jqLite پیاده سازی توابع متداول jQuery برای دستکاری DOM میباشد. اطلاعات بیشتر در اینجا
بنابراین با استفاده تنها از KnockoutJS نمیتوان یک برنامهی کامل SPA توسعه داد ، در کنار آن نیاز به کتابخانههای دیگری مثل jQuery برای مدیریت درخواستهای AJAX و استفاده از دیگر APIها ، Sammy برای routing و RequireJS برای مدیریت وابستگیها میباشد.
در Knockout و در نتیجه Durandal عمل Databinding به این صورت است :
// JavaScript var vm = { firstName = ko.observable('John') }; ko.applyBindings(vm);
<!-- HTML --> <input data-bind="value:firstName"/>
در Angular :
// JavaScript // Inside of a personController this.firstName = 'John';
در Angular همچنین از یک روش Controller As استفاده میشود :
<!-- HTML --> <div ng-controller="personController as vm"> <input ng-model="vm.firstName"/> </div>
اگر تنها نیاز به یک کتابخانهی Databinding باشد ، Knockout گزینهی مناسبی است ، به خوبی از عمل مقید سازی دادهها پشتیبانی میکند و Syntax خوش دستی دارد اما اگر نیاز به چارچوبی برای توسعهی پروژههای SPA میباشد میتوان از Angular یا Durandal استفاده کرد.
مقایسهی Knockout با Angular همانند مقایسهی موتور بنز با ماشین پورشه میباشد.
اشتراکها
مدل پیکره بندی جدید در ASP.NET CORE
ASPNET Core has a lot of changes compared with the others versions of ASP.NET. One change I want to highlight is the new way to configure settings. With previous versions, this configuration was made by using the common file web.config, but this file simply doesn’t exist anymore in ASP.NET Core. Instead, a new easy way to declare and access to the settings is provided. Let’s take a look.
اشتراکها
کتابخانه primereact
مطالب
EF Code First #10
حین کار با ORMهای پیشرفته، ویژگیهای جالب توجهی در اختیار برنامه نویسها قرار میگیرد که در زمان استفاده از کلاسهای متداول SQLHelper از آنها خبری نیست؛ مانند:
الف) Deferred execution
ب) Lazy loading
ج) Eager loading
نحوه بررسی SQL نهایی تولیدی توسط EF
برای توضیح موارد فوق، نیاز به مشاهده خروجی SQL نهایی حاصل از ORM است و همچنین شمارش تعداد بار رفت و برگشت به بانک اطلاعاتی. بهترین ابزاری را که برای این منظور میتوان پیشنهاد داد، برنامه EF Profiler است. برای دریافت آن میتوانید به این آدرس مراجعه کنید: (^) و (^)
پس از وارد کردن نام و آدرس ایمیل، یک مجوز یک ماهه آزمایشی، به آدرس ایمیل شما ارسال خواهد شد.
زمانیکه این فایل را در ابتدای اجرای برنامه به آن معرفی میکنید، محل ذخیره سازی نهایی آن جهت بازبینی بعدی، مسیر MyUserName\Local Settings\Application Data\EntityFramework Profiler خواهد بود.
استفاده از این برنامه هم بسیار ساده است:
الف) در برنامه خود، ارجاعی را به اسمبلی HibernatingRhinos.Profiler.Appender.dll که در پوشه برنامه EFProf موجود است، اضافه کنید.
ب) در نقطه آغاز برنامه، متد زیر را فراخوانی نمائید:
HibernatingRhinos.Profiler.Appender.EntityFramework.EntityFrameworkProfiler.Initialize();
نقطه آغاز برنامه میتواند متد Application_Start برنامههای وب، در متد Program.Main برنامههای ویندوزی کنسول و WinForms و در سازنده کلاس App برنامههای WPF باشد.
ج) برنامه EFProf را اجرا کنید.
مزایای استفاده از این برنامه
1) وابسته به بانک اطلاعاتی مورد استفاده نیست. (برخلاف برای مثال برنامه معروف SQL Server Profiler که فقط به همراه SQL Server ارائه میشود)
2) خروجی SQL نمایش داده شده را فرمت کرده و به همراه Syntax highlighting نیز هست.
3) کار این برنامه صرفا به لاگ کردن SQL تولیدی خلاصه نمیشود. یک سری از Best practices را نیز به شما گوشزد میکند. بنابراین اگر نیاز دارید سیستم خود را بر اساس دیدگاه یک متخصص بررسی کنید (یک Code review ارزشمند)، این ابزار میتواند بسیار مفید باشد.
4) میتواند کوئریهای سنگین و سبک را به خوبی تشخیص داده و گزارشات آماری جالبی را به شما ارائه دهد.
5) میتواند دقیقا مشخص کند، کوئری را که مشاهده میکنید از طریق کدام متد در کدام کلاس صادر شده است و دقیقا از چه سطری.
6) امکان گروه بندی خودکار کوئریهای صادر شده را بر اساس DbContext مورد استفاده به همراه دارد.
و ...
استفاده از این برنامه حین کار با EF «الزامی» است! (البته نسخههای NH و سایر ORMهای دیگر آن نیز موجود است و این مباحث در مورد تمام ORMهای پیشرفته صادق است)
مدام باید بررسی کرد که صفحه جاری چه تعداد کوئری را به بانک اطلاعاتی ارسال کرده و به چه نحوی. همچنین آیا میتوان با اعمال اصلاحاتی، این وضع را بهبود بخشید. بنابراین عدم استفاده از این برنامه حین کار با ORMs، همانند راه رفتن در خواب است! ممکن است تصور کنید برنامه دارد به خوبی کار میکند اما ... در پشت صحنه فقط صفحه جاری برنامه، 100 کوئری را به بانک اطلاعاتی ارسال کرده، در حالیکه شما تنها نیاز به یک کوئری داشتهاید.
کلاسهای مدل مثال جاری
کلاسهای مدل مثال جاری از یک دپارتمان که دارای تعدادی کارمند میباشد، تشکیل شده است. ضمنا هر کارمند تنها در یک دپارتمان میتواند مشغول به کار باشد و رابطه many-to-many نیست :
using System.Collections.Generic;
namespace EF_Sample06.Models
{
public class Department
{
public int DepartmentId { get; set; }
public string Name { get; set; }
//Creates Employee navigation property for Lazy Loading (1:many)
public virtual ICollection<Employee> Employees { get; set; }
}
}
namespace EF_Sample06.Models
{
public class Employee
{
public int EmployeeId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
//Creates Department navigation property for Lazy Loading
public virtual Department Department { get; set; }
}
}
نگاشت دستی این کلاسها هم ضرورتی ندارد، زیرا قراردادهای توکار EF Code first را رعایت کرده و EF در اینجا به سادگی میتواند primary key و روابط one-to-many را بر اساس navigation properties تعریف شده، تشخیص دهد.
در اینجا کلاس Context برنامه به شرح زیر است:
using System.Data.Entity;
using EF_Sample06.Models;
namespace EF_Sample06.DataLayer
{
public class Sample06Context : DbContext
{
public DbSet<Department> Departments { set; get; }
public DbSet<Employee> Employees { set; get; }
}
}
و تنظیمات ابتدایی نحوه به روز رسانی و آغاز بانک اطلاعاتی نیز مطابق کدهای زیر میباشد:
using System.Collections.Generic;
using System.Data.Entity.Migrations;
using EF_Sample06.Models;
namespace EF_Sample06.DataLayer
{
public class Configuration : DbMigrationsConfiguration<Sample06Context>
{
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
}
protected override void Seed(Sample06Context context)
{
var employee1 = new Employee { FirstName = "f name1", LastName = "l name1" };
var employee2 = new Employee { FirstName = "f name2", LastName = "l name2" };
var employee3 = new Employee { FirstName = "f name3", LastName = "l name3" };
var employee4 = new Employee { FirstName = "f name4", LastName = "l name4" };
var dept1 = new Department { Name = "dept 1", Employees = new List<Employee> { employee1, employee2 } };
var dept2 = new Department { Name = "dept 2", Employees = new List<Employee> { employee3 } };
var dept3 = new Department { Name = "dept 3", Employees = new List<Employee> { employee4 } };
context.Departments.Add(dept1);
context.Departments.Add(dept2);
context.Departments.Add(dept3);
base.Seed(context);
}
}
}
نکته: تهیه خروجی XML از نگاشتهای خودکار تهیه شده
اگر علاقمند باشید که پشت صحنه نگاشتهای خودکار EF Code first را در یک فایل XML جهت بررسی بیشتر ذخیره کنید، میتوان از متد کمکی زیر استفاده کرد:
void ExportMappings(DbContext context, string edmxFile)
{
var settings = new XmlWriterSettings { Indent = true };
using (XmlWriter writer = XmlWriter.Create(edmxFile, settings))
{
System.Data.Entity.Infrastructure.EdmxWriter.WriteEdmx(context, writer);
}
}
بهتر است پسوند فایل XML تولیدی را edmx قید کنید تا بتوان آنرا با دوبار کلیک بر روی فایل، در ویژوال استودیو نیز مشاهده کرد:
using (var db = new Sample06Context())
{
ExportMappings(db, "mappings.edmx");
}
الف) بررسی Deferred execution یا بارگذاری به تاخیر افتاده
برای توضیح مفهوم Deferred loading/execution بهترین مثالی را که میتوان ارائه داد، صفحات جستجوی ترکیبی در برنامهها است. برای مثال یک صفحه جستجو را طراحی کردهاید که حاوی دو تکست باکس دریافت FirstName و LastName کاربر است. کنار هر کدام از این تکست باکسها نیز یک چکباکس قرار دارد. به عبارتی کاربر میتواند جستجویی ترکیبی را در اینجا انجام دهد. نحوه پیاده سازی صحیح این نوع مثالها در EF Code first به چه نحوی است؟
using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Linq;
using EF_Sample06.DataLayer;
using EF_Sample06.Models;
namespace EF_Sample06
{
class Program
{
static IList<Employee> FindEmployees(string fName, string lName, bool byName, bool byLName)
{
using (var db = new Sample06Context())
{
IQueryable<Employee> query = db.Employees.AsQueryable();
if (byLName)
{
query = query.Where(x => x.LastName == lName);
}
if (byName)
{
query = query.Where(x => x.FirstName == fName);
}
return query.ToList();
}
}
static void Main(string[] args)
{
// note: remove this line if you received : create database is not supported by this provider.
HibernatingRhinos.Profiler.Appender.EntityFramework.EntityFrameworkProfiler.Initialize();
Database.SetInitializer(new MigrateDatabaseToLatestVersion<Sample06Context, Configuration>());
var list = FindEmployees("f name1", "l name1", true, true);
foreach (var item in list)
{
Console.WriteLine(item.FirstName);
}
}
}
}
نحوه صحیح این نوع پیاده سازی ترکیبی را در متد FindEmployees مشاهده میکنید. نکته مهم آن، استفاده از نوع IQueryable و متد AsQueryable است و امکان ترکیب کوئریها با هم.
به نظر شما با فراخوانی متد FindEmployees به نحو زیر که هر دو شرط آن توسط کاربر انتخاب شده است، چه تعداد کوئری به بانک اطلاعاتی ارسال میشود؟
var list = FindEmployees("f name1", "l name1", true, true);
شاید پاسخ دهید که سه بار : یکبار در متد db.Employees.AsQueryable و دوبار هم در حین ورود به بدنه شرطهای یاد شده و اینجا است که کسانی که قبلا با رویههای ذخیره شده کار کرده باشند، شروع به فریاد و فغان میکنند که ما قبلا این مسایل رو با یک SP در یک رفت و برگشت مدیریت میکردیم!
پاسخ صحیح: «فقط یکبار»! آنهم تنها در زمان فراخوانی متد ToList و نه قبل از آن.
برای اثبات این مدعا نیاز است به خروجی SQL لاگ شده توسط EF Profiler مراجعه کرد:
SELECT [Extent1].[EmployeeId] AS [EmployeeId],
[Extent1].[FirstName] AS [FirstName],
[Extent1].[LastName] AS [LastName],
[Extent1].[Department_DepartmentId] AS [Department_DepartmentId]
FROM [dbo].[Employees] AS [Extent1]
WHERE ([Extent1].[LastName] = 'l name1' /* @p__linq__0 */)
AND ([Extent1].[FirstName] = 'f name1' /* @p__linq__1 */)
IQueryable قلب LINQ است و تنها بیانگر یک عبارت (expression) از رکوردهایی میباشد که مد نظر شما است و نه بیشتر. برای مثال زمانیکه یک IQueryable را همانند مثال فوق فیلتر میکنید، هنوز چیزی از بانک اطلاعاتی یا منبع دادهای دریافت نشده است. هنوز هیچ اتفاقی رخ نداده است و هنوز رفت و برگشتی به منبع دادهای صورت نگرفته است. به آن باید به شکل یک expression builder نگاه کرد و نه لیستی از اشیاء فیلتر شدهی ما. به این مفهوم، deferred execution (اجرای به تاخیر افتاده) نیز گفته میشود.
کوئری LINQ شما تنها زمانی بر روی بانک اطلاعاتی اجرا میشود که کاری بر روی آن صورت گیرد مانند فراخوانی متد ToList، فراخوانی متد First یا FirstOrDefault و امثال آن. تا پیش از این فقط به شکل یک عبارت در برنامه وجود دارد و نه بیشتر.
اطلاعات بیشتر: «تفاوت بین IQueryable و IEnumerable در حین کار با ORMs»
ب) بررسی Lazy Loading یا واکشی در صورت نیاز
در مطلب جاری اگر به کلاسهای مدل برنامه دقت کنید، تعدادی از خواص به صورت virtual تعریف شدهاند. چرا؟
تعریف یک خاصیت به صورت virtual، پایه و اساس lazy loading است و به کمک آن، تا به اطلاعات شیءایی نیاز نباشد، وهله سازی نخواهد شد. به این ترتیب میتوان به کارآیی بیشتری در حین کار با ORMs رسید. برای مثال در کلاسهای فوق، اگر تنها نیاز به دریافت نام یک دپارتمان هست، نباید حین وهله سازی از شیء دپارتمان، شیء لیست کارمندان مرتبط با آن نیز وهله سازی شده و از بانک اطلاعاتی دریافت شوند. به این وهله سازی با تاخیر، lazy loading گفته میشود.
Lazy loading پیاده سازی سادهای نداشته و مبتنی است بر بکارگیری AOP frameworks یا کتابخانههایی که امکان تشکیل اشیاء Proxy پویا را در پشت صحنه فراهم میکنند. علت virtual تعریف کردن خواص رابط نیز به همین مساله بر میگردد، تا این نوع کتابخانهها بتوانند در نحوه تعریف اینگونه خواص virtual در زمان اجرا، در پشت صحنه دخل و تصرف کنند. البته حین استفاده از EF یا انواع و اقسام ORMs دیگر با این نوع پیچیدگیها روبرو نخواهیم شد و تشکیل اشیاء Proxy در پشت صحنه انجام میشوند.
یک مثال: قصد داریم اولین دپارتمان ثبت شده در حین آغاز برنامه را یافته و سپس لیست کارمندان آنرا نمایش دهیم:
using (var db = new Sample06Context())
{
var dept1 = db.Departments.Find(1);
if (dept1 != null)
{
Console.WriteLine(dept1.Name);
foreach (var item in dept1.Employees)
{
Console.WriteLine(item.FirstName);
}
}
}
رفتار یک ORM جهت تعیین اینکه آیا نیاز است برای دریافت اطلاعات بین جداول Join صورت گیرد یا خیر، واکشی حریصانه و غیرحریصانه را مشخص میسازد.
در حالت واکشی حریصانه به ORM خواهیم گفت که لطفا جهت دریافت اطلاعات فیلدهای جداول مختلف، از همان ابتدای کار در پشت صحنه، Join های لازم را تدارک ببین. در حالت واکشی غیرحریصانه به ORM خواهیم گفت به هیچ عنوان حق نداری Join ایی را تشکیل دهی. هر زمانی که نیاز به اطلاعات فیلدی از جدولی دیگر بود باید به صورت مستقیم به آن مراجعه کرده و آن مقدار را دریافت کنی.
به صورت خلاصه برنامه نویس در حین کار با ORM های پیشرفته نیازی نیست Join بنویسد. تنها باید ORM را طوری تنظیم کند که آیا اینکار را حتما خودش در پشت صحنه انجام دهد (واکشی حریصانه)، یا اینکه خیر، به هیچ عنوان SQL های تولیدی در پشت صحنه نباید حاوی Join باشند (lazy loading).
در مثال فوق به صورت خودکار دو کوئری به بانک اطلاعاتی ارسال میگردد:
SELECT [Limit1].[DepartmentId] AS [DepartmentId],
[Limit1].[Name] AS [Name]
FROM (SELECT TOP (2) [Extent1].[DepartmentId] AS [DepartmentId],
[Extent1].[Name] AS [Name]
FROM [dbo].[Departments] AS [Extent1]
WHERE [Extent1].[DepartmentId] = 1 /* @p0 */) AS [Limit1]
SELECT [Extent1].[EmployeeId] AS [EmployeeId],
[Extent1].[FirstName] AS [FirstName],
[Extent1].[LastName] AS [LastName],
[Extent1].[Department_DepartmentId] AS [Department_DepartmentId]
FROM [dbo].[Employees] AS [Extent1]
WHERE ([Extent1].[Department_DepartmentId] IS NOT NULL)
AND ([Extent1].[Department_DepartmentId] = 1 /* @EntityKeyValue1 */)
یکبار زمانیکه قرار است اطلاعات دپارتمان یک (db.Departments.Find) دریافت شود. تا این لحظه خبری از جدول Employees نیست. چون lazy loading فعال است و فقط اطلاعاتی را که نیاز داشتهایم فراهم کرده است.
زمانیکه برنامه به حلقه میرسد، نیاز است اطلاعات dept1.Employees را دریافت کند. در اینجا است که کوئری دوم، به بانک اطلاعاتی صادر خواهد شد (بارگذاری در صورت نیاز).
ج) بررسی Eager Loading یا واکشی حریصانه
حالت lazy loading بسیار جذاب به نظر میرسد؛ برای مثال میتوان خواص حجیم یک جدول را به جدول مرتبط دیگری منتقل کرد. مثلا فیلدهای متنی طولانی یا اطلاعات باینری فایلهای ذخیره شده، تصاویر و امثال آن. به این ترتیب تا زمانیکه نیازی به اینگونه اطلاعات نباشد، lazy loading از بارگذاری آنها جلوگیری کرده و سبب افزایش کارآیی برنامه میشود.
اما ... همین lazy loading در صورت استفاده نا آگاهانه میتواند سرور بانک اطلاعاتی را در یک برنامه چندکاربره از پا درآورد! نیازی هم نیست تا شخصی به سایت شما حمله کند. مهاجم اصلی همان برنامه نویس کم اطلاع است!
اینبار مثال زیر را درنظر بگیرید که بجای دریافت اطلاعات یک شخص، مثلا قصد داریم، اطلاعات کلیه دپارتمانها را توسط یک Grid نمایش دهیم (فرقی نمیکند برنامه وب یا ویندوز باشد؛ اصول یکی است):
using (var db = new Sample06Context())
{
foreach (var dept in db.Departments)
{
Console.WriteLine(dept.Name);
foreach (var item in dept.Employees)
{
Console.WriteLine(item.FirstName);
}
}
}
There is already an open DataReader associated with this Command which must be closed first
برای رفع این مشکل نیاز است گزینه MultipleActiveResultSets=True را به کانکشن استرینگ اضافه کرد:
<connectionStrings>
<clear/>
<add
name="Sample06Context"
connectionString="Data Source=(local);Initial Catalog=testdb2012;Integrated Security = true;MultipleActiveResultSets=True;"
providerName="System.Data.SqlClient"
/>
</connectionStrings>
سؤال: به نظر شما در دو حلقه تو در توی فوق چندبار رفت و برگشت به بانک اطلاعاتی صورت میگیرد؟ با توجه به اینکه در متد Seed ذکر شده در ابتدای مطلب، تعداد رکوردها مشخص است.
پاسخ: 7 بار!
و اینجا است که عنوان شد استفاده از EF Profiler در حین توسعه برنامههای مبتنی بر ORM «الزامی» است! اگر از این نکته اطلاعی نداشتید، بهتر است یکبار تمام صفحات گزارشگیری برنامههای خود را که حاوی یک Grid هستند، توسط EF Profiler بررسی کنید. اگر در این برنامه پیغام خطای n+1 select را دریافت کردید، یعنی در حال استفاده ناصحیح از امکانات lazy loading میباشید.
آیا میتوان این وضعیت را بهبود بخشید؟ زمانیکه کار ما گزارشگیری از اطلاعات با تعداد رکوردهای بالا است، استفاده ناصحیح از ویژگی Lazy loading میتواند به شدت کارآیی بانک اطلاعاتی را پایین بیاورد. برای حل این مساله در زمانهای قدیم (!) بین جداول join مینوشتند؛ الان چطور؟
در EF متدی به نام Include جهت Eager loading اطلاعات موجودیتهای مرتبط به هم درنظر گرفته شده است که در پشت صحنه همینکار را انجام میدهد:
using (var db = new Sample06Context())
{
foreach (var dept in db.Departments.Include(x => x.Employees))
{
Console.WriteLine(dept.Name);
foreach (var item in dept.Employees)
{
Console.WriteLine(item.FirstName);
}
}
}
همانطور که ملاحظه میکنید اینبار به کمک متد Include، نسبت به واکشی حریصانه Employees اقدام کردهایم. اکنون اگر برنامه را اجرا کنیم، فقط یک رفت و برگشت به بانک اطلاعاتی انجام خواهد شد و کار Join نویسی به صورت خودکار توسط EF مدیریت میگردد:
SELECT [Project1].[DepartmentId] AS [DepartmentId],
[Project1].[Name] AS [Name],
[Project1].[C1] AS [C1],
[Project1].[EmployeeId] AS [EmployeeId],
[Project1].[FirstName] AS [FirstName],
[Project1].[LastName] AS [LastName],
[Project1].[Department_DepartmentId] AS [Department_DepartmentId]
FROM (SELECT [Extent1].[DepartmentId] AS [DepartmentId],
[Extent1].[Name] AS [Name],
[Extent2].[EmployeeId] AS [EmployeeId],
[Extent2].[FirstName] AS [FirstName],
[Extent2].[LastName] AS [LastName],
[Extent2].[Department_DepartmentId] AS [Department_DepartmentId],
CASE
WHEN ([Extent2].[EmployeeId] IS NULL) THEN CAST(NULL AS int)
ELSE 1
END AS [C1]
FROM [dbo].[Departments] AS [Extent1]
LEFT OUTER JOIN [dbo].[Employees] AS [Extent2]
ON [Extent1].[DepartmentId] = [Extent2].[Department_DepartmentId]) AS [Project1]
ORDER BY [Project1].[DepartmentId] ASC,
[Project1].[C1] ASC
متد Include در نگارشهای اخیر EF پیشرفت کرده است و همانند مثال فوق، امکان کار با lambda expressions را جهت تعریف خواص مورد نظر به صورت strongly typed ارائه میدهد. در نگارشهای قبلی این متد، تنها امکان استفاده از رشتهها برای معرفی خواص وجود داشت.
همچنین توسط متد Include امکان eager loading چندین سطح با هم نیز وجود دارد؛ مثلا x.Employees.Kids و همانند آن.
چند نکته در مورد نحوه خاموش کردن Lazy loading
امکان خاموش کردن Lazy loading در تمام کلاسهای برنامه با تنظیم خاصیت Configuration.LazyLoadingEnabled کلاس Context برنامه به نحو زیر میسر است:
public class Sample06Context : DbContext
{
public Sample06Context()
{
this.Configuration.LazyLoadingEnabled = false;
}
یا اگر تنها در مورد یک کلاس نیاز است این خاموش سازی صورت گیرد، کلمه کلیدی virtual را حذف کنید. برای مثال با نوشتن public ICollection<Employee> Employees بجای public virtual ICollection<Employee> Employees در اولین بار وهله سازی کلاس دپارتمان، لیست کارمندان آن به نال تنظیم میشود. البته در این حالت null object pattern را نیز فراموش نکنید (وهله سازی پیش فرض Employees در سازنده کلاس):
public class Department
{
public int DepartmentId { get; set; }
public string Name { get; set; }
public ICollection<Employee> Employees { get; set; }
public Department()
{
Employees = new HashSet<Employee>();
}
}
به این ترتیب به خطای null reference object بر نخواهیم خورد. همچنین وهله سازی، با مقدار دهی لیست دریافتی از بانک اطلاعاتی متفاوت است. در اینجا نیز باید از متد Include استفاده کرد.
بنابراین در صورت خاموش کردن lazy loading، حتما نیاز است از متد Include استفاده شود. اگرlazy loading فعال است، جهت تبدیل آن به eager loading از متد Include استفاده کنید (اما اجباری نیست).
از سال 1970 تا به حال سیستمهای مدیریت پایگاه داده عملیاتی – ODBMS - مختلفی ایجاد شدهاند. بعضی از آنها به مرور زمان از بین رفتهاند و برخی قدرتمندتر شدهاند. در دهههای اخیر بین سیستمهای مدیریت پایگاه داده عملیاتی، محصولات شرکتهای اوراکل، مایکروسافت، IBM و SAP از بقیه موفقتر بودهاند. اما مسلما در این بین بهترین سیستم مدیریت پایگاه داده، محصول شرکت اوراکل بوده است و سخن گزافی نیست که بگوییم محصول شرکت اوراکل در دهههای اخیر در بین محصولات دیگر شرکتها پادشاهی میکرده است .
تا حدود 4 سال پیش بین کیفیت oracle db و sql server اختلاف فاحشی وجود داشت. چه از نظر سرعت و چه از نظر دیگر امکانات، اوراکل کاملا برتر از رقیب خود بود. در نسخهی sql server 2012، امکانات قابل توجهی به محصول شرکت مایکروسافت افزوده شد. از مهمترین این امکانات میتوان به ویژگی AlwaysOn و ColumnStore Indexها اشاره کرد. امکانات این نسخه باعث شد که اختلاف بین oracle db و sql server تا حدی کاهش یابد. مایکروسافت سرانجام در نسخهی sql server 2014 خود تغییرات اساسی بوجود آورد. مهمترین این تغییرات ایجاد موتور درونی In-Memory OLTP میباشد که برای تراکنشهای درون حافظه بهینه شده است. با استفاده از امکانات این نسخه میتوان بدون نیاز به دوباره نویسی محصولات، سرعت اجرای کوئریهای آنها را به طور متوسط ده برابر کرد. در شکل ذیل ساختار جدید sql server مشاهده میشود.
شرکت بوین که یک شرکت مشهور ارائه خدمات آنلاین و پیش بینی بازیهای ورزشی است و در هر لحظه، کاربران آنلاین بسیاری در وب سایت شرکت، کوئری اجرا میکنند، از قابلیتهای جدید اس کیو ال سرور 2014 استفاده کرده است و با استفاده از این قابلیتها توانسته سرعت اجرای پرس و جوهای مشتریانش را از 15 هزار پرس و جو در ثانیه به 250 هزار پرس و جو در ثانیه برساند. در نتیجه کارایی سرور این شرکت 16 برابر شده است.
در تحقیقی دیگر، یک محقق، با استفاده از قابلیتهای جدید اس کیو ال سرور 2014 توانسته است دو رکورد جدید را از اجرای کوئریهای انبار داده ای برای حجمهای 3 ترابایت و 10 ترابایت و نوع پارتیشن بندی نشده به ثبت برساند و رکوردهای قبلی را که متعلق به اوراکل بوده، بشکند. این محقق توانسته 404005 کوئری نسبتا سنگین انبار دادهای را در پایگاه دادهای با 10 ترابایت اطلاعات، در یک ساعت اجرا کند و رکورد قبلی را که متعلق به اوراکل و برابر 377594 کوئری با همین شرایط بوده، بشکند. همچنین هزینهی اجرای کوئریهای سرور اس کیو ال مذکور برابر 2.04 دلار در هر ساعت اجرای کوئری بوده است. به این معنی است که کمتر از نصف هزینهی مشابه در رکورد ثبت شدهی اوراکل که برابر 4.65 دلار در ساعت اجرای کوئری بوده است، هزینه داشته است.
شرکت گارتنر معمولا خلاصهی نتیجهی بررسیهای خود را در نمودارهایی خاص به نام مربع جادویی گارتنر ارائه میکند. در این نمودار، قابلیتهای اجرایی که بیانگر کیفیت فعلی محصول هستند، در محور عمودی نمایش داده میشوند و از پایین به بالا زیاد میشوند. یعنی هر چه محصولی بالاتر باشد، در حال حاضر کیفیت بهتری دارد. محور افقی نمودار بیانگر بصیرت و آینده نگری محصول میباشد و از چپ به راست زیاد میشود. به این ترتیب رهبران یک حوزهی خاص، در ربع بالا و سمت راست مربع جای میگیرند.
حال که با نحوهی تفسیر مربع جادویی گارتنر آشنا شدیم، به بررسی نمودارهای مربوط به سیستمهای مدیریت پایگاه داده عملیاتی در سه سال اخیر میپردازیم.
در شکل ذیل میبینیم که در سال 2013 و پس از ارائهی نسخهی sql server 2012 توسط مایکروسافت، اوراکل همچنان پیشتاز است و شرکتهای مایکروسافت، آی بی ام و SAP پس از آن قرار گرفتهاند. البته در این سال شرکت مایکروسافت فاصلهی زیاد قبلی خود را با اوراکل، کم کرده است.
در سال 2014، شرکت مایکروسافت از نظر آینده نگری و بصیرت، از اوراکل پیشی گرفته ولی هنوز در قابلیتهای اجرایی عقبتر از اوراکل قرار دارد.
اما چند روز پیش در تاریخ 12 اکتبر 2015، شرکت گارتنر گزارشی ارائه کرد که خیلی از فعالان آی تی را شگفت زده کرد. این گزارش در حال حاضر در وب سایت شرکت گارتنر قابل دسترسی است؛ ولی معمولا گارتنر پس از مدتی آن را از حالت رایگان به پولی تغییر میدهد.
لینک موقت گزارش
در گزارش سال 2015 و پس از ارائهی نسخهی sql server 2014 و کاربردی شدن و تست قابلیتهای آن در عمل توسط شرکتهای مختلف، بالاخره طلسم چند ده سالهی اوراکل شکسته شده و اگرچه اوراکل نسبت به سال قبل رشد داشته است، ولی sql server مایکروسافت توانسته، هم در قابلیت اجرای فعلی و هم در بصیرت و آینده نگری بالاتر از محصول شرکت اوراکل بایستد. بنابراین عملا دوران پادشاهی مطلق اوراکل در حوزهی پایگاههای دادهی عملیاتی به سر رسیده است.
- شرکت اوراکل بر خلاف تصور خیلی از افراد، همانند شرکتهای مایکروسافت، آی بی ام و ... محصولات گسترده و مختلفی دارد و این بررسی و نتایج تنها در حوزهی سیستمهای مدیریت پایگاه داده عملیاتی بود.
- بالاتر بودن sql server مایکروسافت از اوراکل در سال 2015 به این معنا نیست که اوراکل نمیتواند به جایگاه قبلی خود برگردد؛ بلکه شاید در سالهای آینده این رتبه بندی باز هم تغییر کند. در واقع این گزارش به این معنا است که فاصلهی زیاد قدیم بین sql server و oracle db از بین رفته و در حال حاضر این دو به رقیب سر سختی برای یکدیگر تبدیل شدهاند.
- وجود رقابت نزدیک بین شرکتهای بزرگ باعث میشود که این شرکتها حداکثر تلاش خود را برای بهتر کردن محصولات خود انجام بدهند و برندگان اصلی این وضعیت، استفاده کنندگان از این محصولات هستند.
- بنده به عنوان نگارندهی این پست شخصا با هر دو محصول oracle db و sql server کار میکنم و تلاش کردم که این پست بی طرفانه باشد؛ پس لطفا متعصبانه قضاوت نکنید.
تا حدود 4 سال پیش بین کیفیت oracle db و sql server اختلاف فاحشی وجود داشت. چه از نظر سرعت و چه از نظر دیگر امکانات، اوراکل کاملا برتر از رقیب خود بود. در نسخهی sql server 2012، امکانات قابل توجهی به محصول شرکت مایکروسافت افزوده شد. از مهمترین این امکانات میتوان به ویژگی AlwaysOn و ColumnStore Indexها اشاره کرد. امکانات این نسخه باعث شد که اختلاف بین oracle db و sql server تا حدی کاهش یابد. مایکروسافت سرانجام در نسخهی sql server 2014 خود تغییرات اساسی بوجود آورد. مهمترین این تغییرات ایجاد موتور درونی In-Memory OLTP میباشد که برای تراکنشهای درون حافظه بهینه شده است. با استفاده از امکانات این نسخه میتوان بدون نیاز به دوباره نویسی محصولات، سرعت اجرای کوئریهای آنها را به طور متوسط ده برابر کرد. در شکل ذیل ساختار جدید sql server مشاهده میشود.
شرکت بوین که یک شرکت مشهور ارائه خدمات آنلاین و پیش بینی بازیهای ورزشی است و در هر لحظه، کاربران آنلاین بسیاری در وب سایت شرکت، کوئری اجرا میکنند، از قابلیتهای جدید اس کیو ال سرور 2014 استفاده کرده است و با استفاده از این قابلیتها توانسته سرعت اجرای پرس و جوهای مشتریانش را از 15 هزار پرس و جو در ثانیه به 250 هزار پرس و جو در ثانیه برساند. در نتیجه کارایی سرور این شرکت 16 برابر شده است.
در تحقیقی دیگر، یک محقق، با استفاده از قابلیتهای جدید اس کیو ال سرور 2014 توانسته است دو رکورد جدید را از اجرای کوئریهای انبار داده ای برای حجمهای 3 ترابایت و 10 ترابایت و نوع پارتیشن بندی نشده به ثبت برساند و رکوردهای قبلی را که متعلق به اوراکل بوده، بشکند. این محقق توانسته 404005 کوئری نسبتا سنگین انبار دادهای را در پایگاه دادهای با 10 ترابایت اطلاعات، در یک ساعت اجرا کند و رکورد قبلی را که متعلق به اوراکل و برابر 377594 کوئری با همین شرایط بوده، بشکند. همچنین هزینهی اجرای کوئریهای سرور اس کیو ال مذکور برابر 2.04 دلار در هر ساعت اجرای کوئری بوده است. به این معنی است که کمتر از نصف هزینهی مشابه در رکورد ثبت شدهی اوراکل که برابر 4.65 دلار در ساعت اجرای کوئری بوده است، هزینه داشته است.
در واقع اگر بخواهیم سیستمهای مدیریت پایگاه داده عملیاتی را رتبه بندی کنیم، به جز سرعت، باید عوامل مختلفی را در نظر بگیریم که چنین کاری نیاز به همکاری گروهی بزرگ دارد. خوشبختانه چنین گروههایی وجود دارند و آن قدر معتبر هستند که اکثر شرکتهای بزرگ به آمارهای آنها استناد میکنند. در فناوریهای مربوط به آی تی، برای رسیدن به معتبرترین نتایج باید به گزارشهای ارائه شدهی شرکت گارتنر رجوع کنیم. گارتنر، شرکت پژوهشی و مشاورهی آمریکایی است، که در زمینهی ارائه خدمات برونسپاری، تحقیق و پژوهش و مشاوره فناوری اطلاعات فعالیت مینماید. این شرکت در سال 1979 راهاندازی شد و در سال 2014 بیش از 6500 نفر کارمند داشته که در 85 کشور بودهاند. در این بین حدود 1500 نفر از آنها در بخش تحقیق و توسعه فعالیت داشتهاند. همچنین در این سال، درآمد شرکت گارتنر که عمدتا از طریق مشاوره دادن به شرکتهای مختلف بوده، بیش از 2 میلیارد دلار در سال 2014 بوده است.
شرکت گارتنر معمولا خلاصهی نتیجهی بررسیهای خود را در نمودارهایی خاص به نام مربع جادویی گارتنر ارائه میکند. در این نمودار، قابلیتهای اجرایی که بیانگر کیفیت فعلی محصول هستند، در محور عمودی نمایش داده میشوند و از پایین به بالا زیاد میشوند. یعنی هر چه محصولی بالاتر باشد، در حال حاضر کیفیت بهتری دارد. محور افقی نمودار بیانگر بصیرت و آینده نگری محصول میباشد و از چپ به راست زیاد میشود. به این ترتیب رهبران یک حوزهی خاص، در ربع بالا و سمت راست مربع جای میگیرند.
حال که با نحوهی تفسیر مربع جادویی گارتنر آشنا شدیم، به بررسی نمودارهای مربوط به سیستمهای مدیریت پایگاه داده عملیاتی در سه سال اخیر میپردازیم.
در شکل ذیل میبینیم که در سال 2013 و پس از ارائهی نسخهی sql server 2012 توسط مایکروسافت، اوراکل همچنان پیشتاز است و شرکتهای مایکروسافت، آی بی ام و SAP پس از آن قرار گرفتهاند. البته در این سال شرکت مایکروسافت فاصلهی زیاد قبلی خود را با اوراکل، کم کرده است.
در سال 2014، شرکت مایکروسافت از نظر آینده نگری و بصیرت، از اوراکل پیشی گرفته ولی هنوز در قابلیتهای اجرایی عقبتر از اوراکل قرار دارد.
اما چند روز پیش در تاریخ 12 اکتبر 2015، شرکت گارتنر گزارشی ارائه کرد که خیلی از فعالان آی تی را شگفت زده کرد. این گزارش در حال حاضر در وب سایت شرکت گارتنر قابل دسترسی است؛ ولی معمولا گارتنر پس از مدتی آن را از حالت رایگان به پولی تغییر میدهد.
لینک موقت گزارش
در گزارش سال 2015 و پس از ارائهی نسخهی sql server 2014 و کاربردی شدن و تست قابلیتهای آن در عمل توسط شرکتهای مختلف، بالاخره طلسم چند ده سالهی اوراکل شکسته شده و اگرچه اوراکل نسبت به سال قبل رشد داشته است، ولی sql server مایکروسافت توانسته، هم در قابلیت اجرای فعلی و هم در بصیرت و آینده نگری بالاتر از محصول شرکت اوراکل بایستد. بنابراین عملا دوران پادشاهی مطلق اوراکل در حوزهی پایگاههای دادهی عملیاتی به سر رسیده است.
در انتها لازم میبینم به نکاتی مهم اشاره کنم:
- شرکت اوراکل بر خلاف تصور خیلی از افراد، همانند شرکتهای مایکروسافت، آی بی ام و ... محصولات گسترده و مختلفی دارد و این بررسی و نتایج تنها در حوزهی سیستمهای مدیریت پایگاه داده عملیاتی بود.
- بالاتر بودن sql server مایکروسافت از اوراکل در سال 2015 به این معنا نیست که اوراکل نمیتواند به جایگاه قبلی خود برگردد؛ بلکه شاید در سالهای آینده این رتبه بندی باز هم تغییر کند. در واقع این گزارش به این معنا است که فاصلهی زیاد قدیم بین sql server و oracle db از بین رفته و در حال حاضر این دو به رقیب سر سختی برای یکدیگر تبدیل شدهاند.
- وجود رقابت نزدیک بین شرکتهای بزرگ باعث میشود که این شرکتها حداکثر تلاش خود را برای بهتر کردن محصولات خود انجام بدهند و برندگان اصلی این وضعیت، استفاده کنندگان از این محصولات هستند.
- بنده به عنوان نگارندهی این پست شخصا با هر دو محصول oracle db و sql server کار میکنم و تلاش کردم که این پست بی طرفانه باشد؛ پس لطفا متعصبانه قضاوت نکنید.
فلسفهی بوجود آمدن زبان Typescript یکی از شنیدنیترینها در دنیای برنامهنویسی است. به یاد دارم روزهای اولی که با این زبان آشنا شدم (زمانی که حدوداً ورژن 0.6 منتشر شده بود)، افراد زیادی در مورد این زبان و اینکه آیا اصلاً به این زبان احتیاج داریم یا نه نظرات زیادی دادند. مثلاً Douglas Crockford در مورد این زبان بعد از تعریف و تمجیدهایی که از Anders Hejlsberg کرده گفته :
I think that JavaScript's loose typing is one of its best features and that type checking is way overrated. TypeScript adds sweetness, but at a price. It is not a price I am willing to pay.
اما به مرور زمان این زبان توفیق بیشتری پیدا کرد تا اینکه امروز پروژههای بسیار جالبی با این زبان در حال توسعه هستند.
چرا باید در مورد Typescript بدانیم؟
زبان Typescript نقاط قوت بسیاری دارد، از جملهی آنها میتوان به موارد زیر اشاره کرد:
- این زبان یکی از مشکلات اصلی JavaScript را که نبودن Type Safety میباشد حل کردهاست. اگر چه زبانی که type safe نباشد بسیاری اوقات مزیت است! زبان typescript در حقیقت یک زبان gradual typing است.
- از آنجایی که typescript یک super set از زبان JavaScript است، برنامهنویس در لحظه از مزایای زبان JavaScript هم بهرهمند است. مهمتر از آن این است که در زبان typescript به اقیانوس کتابخانههای JavaScript دسترسی دارید. این امکان در بسیاری زبانهای دیگر جایگزین JavaScript وجود ندارد. حتی بهتر از آن، میتواند با این کتابخانهها بهصورت type safe برنامه بنویسید. تصور کنید که وقتی با $ در JQuery کار میکنید بتوانید از امکان intellisense استفاده کنید.
- بازهم از آنجا که typescript یک super set از JavaScript است، typescript قرار نیست به اسمبلی کامپایل شود؛ بلکه به زبان شناخته شدهای به نام JavaScript تبدیل میشود. بنابراین حتی میتوان از آن JavaScript نیز یاد گرفت.
- کار با زبان typescript برای کسانی که با java یا سی شارپ آشنا هستند، راحت است. امکاناتی مانند genericها نیز در typescript وجود دارد.
- نقشهی راه typescript با EcmaScript هماهنگ است. بنابراین از یادگرفتن این زبان ضرر نمیکنید چون قابلیتهای این زبان را به احتمال زیاد در نسخهی بعدی EcmaScript خواهید دید.
- این زبان توسط شرکت مایکروسافت پشتیبانی میشود، اوپن سورس است و تجربهی Anders Hejlsberg در زمینهی طراحی زبانهای برنامهنویسی پشتیبان آن!
- پروژههای جالبی که در ادامه به معرفی آنها میپردازیم، با این زبان در حال توسعه هستند.
در این مطلب تعدادی از این پروژهها را که برای خودم جذاب هستند، به شما معرفی میکنم.
AngularJS 2
طبیعتاً مهمترین اتفاقی که برای typescript در این روزهای اخیر افتاد این بود که تیم Angular اعلام کرد که نسخهی ۲ این فریمورک (که این روزها در حد JQuery در وب معروف شده و استفاده میشود) را با زبان Typescript توسعه میدهد و امکاناتی که قرار بود توسط زبان AtScript پیادهسازی شوند، به کمک Typescript توسعه پیدا میکنند. تیم Typescript هم بلافاصله اعلام کرد که در نسخهی 1.5 که بهزودی منتشر میشود بسیاری از امکانات AtScript قرار خواهد داشت. بنابراین میتوانید منتظر قابلیتی شبیه به Attributeهای سیشارپ در typescript 1.5 باشید.
همانطور که میدانید AngularJS مهمترین فریمورک حال حاضر است که برای توسعهی نرمافزارهای SPA وجود دارد. اعلام توسعهی Angular 2 بهوسیلهی Typescript مطمئناً خبر خوبی برای برنامهنویسان typescript خواهد بود، چون این اتفاق باعث بهبود سریعتر این زبان میشود.
Definitely Typed
اگرچه نمیتوان این پروژه را در سطح دیگر پروژههایی که در این مقاله معرفی میشود قرار داد، ولی اهمیت آن من را مجبور کرد که در این مقاله در موردش صحبت کنم. پروژهی Definitely Typed در حقیقت استفاده از کتابخانههای دیگر JavaScript را در typescript ممکن میسازد. این پروژه برای پروژههای دیگری مانند JQuery، AngularJS، HighCharts، Underscore و هر چیزی که فکرش را بکنید Type Definition تعریف کرده. اگر هم کتابخانهای که شما میخواستید در این پروژه نبود، دلیلش این است که اضافه کردن آن را به شما واگذار کردهاند! Type Definitionها در Typescript یکی از قابلیتهای این زبان هستند برای اینکه بتوان با کتابخانههای JavaScript بهصورت Type safe کار کرد.
shumway
حتماً از شنیدن اینکه این پروژه قرار است چه کاری انجام دهد شوکه خواهید شد! shumway که توسط موزیلا توسعه مییابد قرار است همان flash player باشد! البته این پروژه هنوز در مراحل اولیهی توسعه است ولی اگر بخواهید میتوانید دموی این پروژه را اینجا ببینید.
Fayde
پروژهی Fayde هم Silverlight را هدف گرفته است. البته مانند shumway موسسهی معروفی از آن حمایت نمیکند.
Doppio
پروژهی Doppio در حقیقت یک Java Virtual Machine است که روی Browser هم میتواند اجرا شود. از جمله کارهای جالبی که با این پروژه میتوان کرد، کامپایل کردن کد جاوا، Disassemble کردن یک فایل class، اجرای یک فایل JAR و حتی ارتباط با JavaScript هستند.
TypeFramework
این پروژه برای افرادی خوب است که هم به NodeJS علاقمند هستند و هم به ASP.NET MVC. پروژهی TypeFramework در حقیقت پیادهسازی مدل ASP.NET MVC در NodeJS است. Controllerها، Actionها، ActionResultها و حتی ActionFilterها با همان تعریف موجود در ASP.NET MVC در این فریمورک وجود دارند.
MAYHEM
این پروژه یک فریمورک کاملی برای طراحی و توسعهی نرمافزارهای Enterprise است. در شرح این پروژه آمده است که بر خلاف اینکه همهی فریمورکها روی حجم فایل، سرعت و... تمرکز دارند این پروژه بر درستی معماری تأکید دارد. احتمالاً استفاده از این فریمورک برای پروژههای طولانی مدت و بزرگ مناسب است. اگرچه از طرف دیگر احتمالاً یاد گرفتن این فریمورک هم کار سختی خواهد بود.
حرف آخر
حرف آخر اینکه به نظر میرسد Typescript زبانی است که ارزش وقت گذاشتن دارد و اگر خواستید Typescript را یاد بگیرید نگاه کردن به کدهای این پروژهها حتماً کلاس درس پرباری خواهد بود. چه کسی میداند، شاید شما بخواهید در توسعهی یکی از این پروژهها مشارکت کنید!
اشتراکها
نگاهی به Windows Package Manager 1.0
Benefits of a package manager
- Check the version of any program or package
- Update the Existing Version you already installed
- Download and install in just one Command
- Automates the process of installing, upgrading, configuring, and removing computer programs
- Upgrade all the program at once
- Export list of program that you've installed and install them back whenever you required