نظرات مطالب
شروع به کار با EF Core 1.0 - قسمت 11 - بررسی رابطه‌ی Self Referencing
- شما در هر دو حالت، دارای لیست منوهایی با 5 آیتم هستید. یعنی خروجی نهایی هر دو کوئری یکی هست و متد Cacheable درست عمل کرده‌است.
- اینکه در کوئری بعدی LINQ to Objects شما، در حالت بدون Cacheable، «امکانات debug visualizer ویژوال استودیو» موفق به تشکیل روابط شده‌است، صرفا به عدم فراخوانی متد AsNoTracking در کوئری غیر کش شده‌ی شما بر می‌گردد. متد AsNoTracking جهت کاهش سربار کوئری‌های EF و حذف پروکسی‌های آن به صورت خودکار توسط متد  Cacheable اعمال می‌شود؛ چون این نوع کوئری‌های کش شده صرفا مختص به گزارشگیری هستند.
- اگر AsNoTracking فراخوانی شود، برای تشکیل روابط صرفا باید از متدهای Include و ThenInclude برای واکشی سطوح دیگر به هم مرتبط استفاده کنید. همچنین هر Include یا ThenInclude فقط یک سطح را واکشی می‌کند.
«...
بدیهی است در اینجا هنوز روش‌های Include و ThenInclue هم جواب می‌دهند؛ اما چون Lazy loading فعال نیست، عملا نمی‌توان تمام زیر ریشه‌ها را یافت ...»

در کل، کوئری دوم شما (حاصل نهایی واکشی تمام عناصر یک جدول) متصل به Context نیست و LINQ to Objects است. بنابراین زمانیکه لیست کامل عناصر را در حافظه‌ی سمت کلاینت دارید (و در اینجا هر عملی بر روی این لیست دوم، نیازی به رفت و برگشت به بانک اطلاعاتی را ندارد)، تشکیل درخت آن‌ها کار مشکلی نیست؛ چون هر آیتم، توسط خاصیت MenuId، به قبلی متصل است و یا خیر. در مثال زیر، لیست نهایی، بر اساس ReplyIdها (دقیقا همان اطلاعات اصلی که در بانک اطلاعاتی ذخیره می‌شود)، حاوی لیست Children چند سطحی خواهد شد. زمانی هم که این لیست را داشتید، از کلاس TreeViewHelper برای نمایش آن استفاده کنید.
        void buildTreeLinqToObjects()
        {
            var comment1 = new BlogComment { Id = 1, Body = "نظر من این است که" };
            var comment12 = new BlogComment { Id = 2, Body = "پاسخی به نظر اول", ReplyId = 1 };
            var comment121 = new BlogComment { Id = 3, Body = "پاسخی به پاسخ به نظر اول", ReplyId = 2 };

            var comment2 = new BlogComment { Id = 4, Body = "نظر من این بود که" };
            var comment22 = new BlogComment { Id = 5, Body = "پاسخی به نظر قبلی", ReplyId = 4 };
            var comment221 = new BlogComment { Id = 6, Body = "پاسخی به پاسخ به نظر من اول", ReplyId = 5 };

            var list = new List<BlogComment>
            {
                comment1, comment12, comment121,
                comment2, comment22, comment221
            };

            foreach (var item in list)
            {
                if (item.ReplyId == null)
                {
                    continue;
                }

                var parent = list.First(x => x.Id == item.ReplyId.Value);
                parent.Children.Add(item);
            }

        }
نظرات مطالب
ارسال انواع بی نام (Anonymous) بازگشتی توسط Entity framework به توابع خارجی
ممنون از نکاتی که ذکر کردید . از نکات ذکر شده برجسته ترینش استفاده از انواع dynamic هستش که کار رو ساده میکنه ولی خب مشکلاتی رو هم به وجود میاره مثلا اشکال زدایی رو سخت میکنه. هر چند که این نوع کار خودش رو با Reflection در زمان اجرا انجام میده و استفاده از اون رو ساده میکنه ولی خب استفاده مستقیم از روش‌های سطح پایین‌تر مزایایی رو هم داره مثلا مثال زیر رو در نظر بگیرید   
       public bool sample(object query)
        {
            System.Reflection.BindingFlags flags = System.Reflection.BindingFlags.Public | 
                System.Reflection.BindingFlags.NonPublic |
                System.Reflection.BindingFlags.Static | 
                System.Reflection.BindingFlags.Instance | 
                System.Reflection.BindingFlags.DeclaredOnly;
            foreach (var item in query.GetType().GetProperties(flags))
            {

                string test = item.GetValue(query,null).ToString();
                // Do Something ...
            }
            return false;
        }
خب حلا فرض کنید ما میخوایم یک Table Generator بسازیم که بر اساس لیست نتایج بازگشتی توسط query بازگشت داده شده توسط Entity framework یک جدول رو برامون ایجاد میکنه . طبیعی هست که هر بار ما یک نوع داده ای بی نام رو براش ارسال میکنیم اگه ما بخوایم نوع dynamic رو به عنوان پارامتر تابع تعریف کنیم نمیتونیم به فیلد‌های نوع بی نام دسترسی داشته باشیم  چرا که هر بار فیلدها فرق میکنه و این تابع قراره در زمان اجرا فیلدها رو تشخیص بده ولی در انواع dynamic ما نام فیلد رو در زمان طراحی مشخص میکنیم و در زمان اجرا توسط نوع dynamic بسط داده میشه که این موضوع واسه همچین مواردی کارایی نداره ... و باید در نظر داشته که انواع dynamic فقط میتونن به فیلد‌های public دسترسی داشته باشن ولی ما با reflection میتونیم محدوده‌ی دسترسی رو مشخص کنیم...
و اما در رابطه با مطلب بالا : بر فرض ما مجموعه ای از داده‌ها رو توسط Entity framework  واکشی کردیم و یک نوع بی نام داریم و حالا میخوایم مثلا با  Table Generator فرضی دو جدول رو از همین یک بار واکشی ایجاد کنیم که هر کدوم شامل یک سری فیلدها هستن و یک سری فیلد‌ها رو از نوع بی نام واکشی شده شامل نمیشن . ما میتونیم یک تابع داشته باشیم که لیست نوع بی نام مرجع رو براش ارسال کنیم و یک نوع بی نام هم به عنوان یک پارامتر به صورت inline براش بفرستیم که فیلدهای مورد نظرمون رو از نوع بی نام مرجع شامل میشه . حالا با کمی توسعه CreateGenericListFromAnonymous و مپ کردن نوع بی نام مرجع با نوع بی نام ارسال شده توسط پارامتر و استفاده از Reflection میتونیم فقط فیلدهایی رو که به صورت inline مشخص کردیم داشته باشیم و با یک بار واکشی اطلاعات چندین بار اون رو با شکل‌های مختلف پردازش کنیم و .... این فقط یک مثال بود و مطلب بالا صرفا ایده ای بود که دوستان بتونن کارهای خلاقانه ای رو از طریق اون انجام بدن ....
مطالب
آموزش زبان Rust - قسمت 12 - Implementation Blocks
در Rust، پیاده سازی فانکشن‌ها ( implementation block ) به ما اجازه می‌دهد تا عملکردی را برای یک type مشخص، تعریف کنیم که ایجاد روش‌ها و توابع مرتبط برای انواع داده‌های سفارشی‌مان را ممکن می‌سازد. در این مقاله، نحوه‌ی استفاده از implementation block را برای تعریف متدها و توابع مرتبط در Rust، با استفاده از ساختار Product به عنوان مثال، بررسی خواهیم کرد. 

ابتدا، بیایید یک struct محصول را با فیلدهای زیر تعریف کنیم: 
struct Product {
    name: String,
    price: f32,
    in_stock: bool,
}

پیاده سازی اجرای روش محاسبه مالیات فروش برای struct product

در ادامه بیایید تابع catalog_sales_tax را به عنوان روشی برای ساختار Product، با استفاده از یک implementation block اضافه کنیم.
impl Product {
    fn calculate_sales_tax(&self) -> f32 {
        self.price * 0.1
    }
}
در این مثال، از کلمه‌ی کلیدی Self، برای ارجاع به نمونه محصولی که این تابع با آن فراخوانی می‌شود، استفاده می‌شود؛ به عبارت دیگر وقتی از Self استفاده میکنید، یعنی دارید خود Product را صدا میزنید و به فیلدهای آن دسترسی دارید.

استفاده از متد در تابع اصلی

اکنون می‌توانیم یک نمونه محصول را ایجاد کنیم و از روش محاسبه مالیات استفاده کنیم:
fn main() {
    let book = Product {
        name: String::from("Book"),
        price: 28.85,
        in_stock: true,
    };
    
    let sales_tax = book.calculate_sales_tax();
    println!("Sales tax: {}", sales_tax);
}

انواع مختلف Self
Immutable borrow (در مواردی استفاده می‌شود که می‌خواهید به سادگی از فیلدهای خود بدون تغییر چیزی استفاده کنید):
fn calculate_sales_tax(&self) -> f32 {
    self.price * 0.1
}

Mutable borrow  (در مواردی که می‌خواهید فیلدهای خود را تغییر دهید استفاده می‌شود): 
fn set_price(&mut self, price: f32) {
    self.price = price;
}

Owned form  (مالکیت نمونه به متد منتقل شده و نمونه در پایان متد حذف می‌شود و دیگر معتبر نیست): 
fn buy(self) {
    let name: String = self.name;
    println!("{} was bought", name);
}

Associated Functions

Associated functions  از کلمه کلیدی self استفاده نمی‌کنند و با استفاده از سینتکس :: فراخوانی می‌شوند. با این حال، هنگام فراخوانی توابع مرتبط در متدهایی که از self استفاده می‌کنند، '.' بجای آن از سینتکس '::' استفاده می‌شود: 

impl Product {
    fn new(name: String, price: f32) -> Product {
        Product {
            name,
            price,
            in_stock: true,
        }
    }
}

اکنون، می‌توانیم یک نمونه محصول را با استفاده از تابع جدید مرتبط ایجاد کنیم:

fn main() {
    let book = Product::new(String::from("Book"), 30.0);
}

در این مقاله، بررسی کردیم که چگونه Implementation Blocks در Rust به ما اجازه می‌دهند تا عملکردی را برای انواع داده‌های سفارشی، مانند روش‌ها و توابع مرتبط تعریف کنیم. با درک اشکال مختلف self و نحوه‌ی استفاده از آنها، می‌توانید روش‌های قدرتمند و انعطاف پذیری را برای انواع داده‌های سفارشی خود در Rust پیاده سازی کنید.  
مطالب
متد جدید Chunk در دات نت 6
متد جدید ()Chunk در دات نت 6، به مجموعه‌ی LINQ اضافه شده‌است. این متد امکانی را فراهم میکند که بتوان مجموعه‌ای را به گروه‌های کوچکتر، تقسیم کنیم .


وضعیت فعلی  پیاده سازی این قابلیت 
در نسخه‌های قبلی دات نت، چنین قابلیتی برای تقسیم یک مجموعه، به مجموعه‌های کوچکتر بصورت توکار وجود ندارد.
مجموعه‌ی زیر را در نظر بگیرید:
int[] numbers = new int[] {6, 5, 1, 9, 18, 5, 3, 21};
این عملیات تقسیم به مجموعه‌های کوچکتر می‌تواند توسط متد‌های Take و Skip، انجام شود که نتیجه نهایی آنچنان چشم نواز نیست!
var coll1 = numbers.Take(2);
var coll2 = numbers.Skip(2).Take(2);
var coll3 = numbers.Skip(4).Take(2);
var coll4 = numbers.Skip(6).Take(2);

با کمی تامل شاید بتوان روش‌های بهتری نیز برای این نیاز ارائه کرد. در این پرسش و پاسخ که رای بالایی هم دارد، یک متد الحاقی برای تقسیم یک مجموعه، به زیر مجموعه‌های کوچکتر ارائه شده‌است:
static class LinqExtensions
{
    public static IEnumerable<IEnumerable<T>> Split<T>(this IEnumerable<T> list, int parts)
    {
        int i = 0;
        var splits = from item in list
                     group item by i++ % parts into part
                     select part.AsEnumerable();
        return splits;
    }
}

پیاده سازی جدید
در دات نت 6، متد جدید Chunk می‌تواند یک مجموعه را به زیر مجموعه‌های کوچکتری تبدیل کند.
فرض کنید یک مجموعه‌ی بزرگ از اعداد تصادفی را داریم:
List<int> numbers = new();

int counter = 0;
Random rand = new(DateTime.Now.Millisecond);
while(counter < 100)
{
    numbers.Add(rand.Next(1, 1000));
    counter++;
}
با استفاده از متد Chunk میتوان این مجموعه‌ی 100 عضوی را به 10 مجموعه‌ی 10 عضوی، تبدیل کرد. این متد مقداری را بعنوان پارامتر دریافت میکند که سایز زیر مجموعه‌هایی است که قرار است تولید شوند.

شرایط خاص در این متد
اگر با تقسیم مجموعه‌ی بزرگتر، زیر مجموعه‌ها تعداد یکسانی عضو نداشتند، چه اتفاقی می‌افتد؟
فرض کنید مجموعه‌ی اصلی 100 عضو و زیر مجموعه‌ها 8 عضو داشته باشند:
IEnumerable<int[]> sublists = numbers.Chunk(8);
چند زیر مجموعه تولید خواهد شد؟ هر مجموعه چند عضو را خواهد داشت؟
خروجی تابع Chunk، سیزده زیر مجموعه دارد؛  12 زیر مجموعه‌ی اول آن، 8 عضوی است که خارج قسمت صحیح تقسیم عدد 100 بر عدد 8 می‌باشد و مجموعه‌ی آخر آن، 4 عضوی است که باقیمانده‌ی تقسیم صحیح 100 بر 8 است. در زمانیکه تعداد زیر مجموعه‌ها فرد است، به این رفتار دقت داشته باشید.
  محاسبه‌ی میانگین ششمین زیر مجموعه‌ی تولید شده در قسمت فوق :
var avg=sublists.ElementAt(6).Average();
مطالب
بررسی روش نصب و استفاده از پیش نمایش NET Core 2.2.

نسخه net core 2.2. Preview 3.، روز چهارشنبه 25 مهر، مطابق با 17 اکتبر منتشر شد. این نسخه شامل ویژگی‌های جدیدی از جمله موارد زیر می‌باشد:

  • تغییرات عمده در API 
  • Authorization Server
  • بهبود کارآیی و سرعت
  • پشتیبانی از Spatial Data برای SQL Server و SQLite
  • پشتیبانی از Cosmos DB
  • جایگزینی Bootstrap 4, Angular 6

مهمترین ویژگی مربوط به EF Core برای گروهی از برنامه نویسان، پشتیبانی از فیلدهای جغرافیایی یا همان Spatial Data می‌باشد.

نسخه‌ی net core 2.2 RTM.،  قبل از انتهای سال میلادی جاری منتشر خواهد شد و پس از آن آغاز به کار بر روی net core 3. خواهد بود. برای  نسخه‌ی net Core 3.، هدف بهبود برنامه‌های مبتنی بر Desktop و سازگاری آن با فرمت جدید csproj، اعلام شده‌است.


برای استفاده از ویژگی‌های net core 2.2. باید نسخه‌ی visual studio 2017 preview، یعنی ورژن Version 15.9.0 به بعد را نصب کنید. اگر صرفا dotnet core 2.2 را نصب کنید و از ویژوال استودیوی جاری قصد استفاده را داشته باشید، به شما پیغام می‌دهد که این نسخه قابلیت استفاده از دات نت 2.2 به بعد را ندارد.



برای تست و استفاده از net core 2.2 preview 3. مراحل زیر را طی کنید:

1- ابتدا آخرین انتشار ویژوال استودیو 2017، یعنی نسخه‌ی ‌پیش‌نمایش preview را از اینجا دریافت و نصب کنید. نسخه Enterprise را انتخاب کنید تا installer دانلود شود وشروع به نصب کند. حجم این نسخه، از نسخه‌ی اصلی کمتر می‌باشد.

                                                 پس از نصب، این نسخه را می‌توانید در کنار نسخه‌ی اصلی، همزمان بر روی سیستم داشته باشید. 

2- سپس net core 2.2. را به یکی از روش‌های زیر نصب کنید:
  • برای نصب کلی بر روی سیستم،  اینجا کلیک کنید و نسخه‌ی SDK Installer مناسب دستگاه خود را دانلود کنید (64 یا 32 بیتی).
         در صورت موفقیت آمیز بودن، صفحه‌ی پایانی را به شکل زیر خواهید دید:

  • برای استفاده‌ی از EF Core آن در پروژه جاری می‌توانید آن‌‌را از اینجا  دانلود و یا بوسیله‌ی دستور زیر نصب کنید:
Install-Package Microsoft.EntityFrameworkCore -Version 2.2.0-preview3-35497

3- پس از نصب، ویژوال استودیوی preview را از همان مسیر visual studio، اجرا کنید. یک پروژه‌ی جدید از نوع وب را ایجاد کنید و فریمورک را بر روی بالاترین مقدار آن قرار دهید؛ مثل تصویر زیر:


بعد از ایجاد پروژه، می‌توانید در solution Explorer، ارجاعات جدید را مشاهده کنید:


مطالب
بررسی Bad code smell ها: دلال یا Middle Man
دلال یا Middle man در دسته الگوهای «کدهایی بیش از اندازه وابسته به هم» قرار می‌گیرد. زمانیکه یک کلاس، تنها کاری را که انجام می‌دهد، هدایت فراخوانی به کلاس دیگری باشد، با این الگو مواجه هستیم. تشخیص این کد بد بو معمولا بسیار آسان است.  
به طور مثال:  
 public class ProductQuery 
    { 
        public dynamic GetProductsByCustomerId(int id) 
        { 
            return new ExpandoObject(); 
        } 
    } 
    public class CustomerQuery 
    { 
        private readonly ProductQuery _productQuery; 
  
        public CustomerQuery(ProductQuery productQuery) 
        { 
            _productQuery = productQuery; 
        } 
        public dynamic GetProducts(int customerId) 
        { 
            return _productQuery.GetProductsByCustomerId(customerId); 
        } 
    } 
    public static class Programm 
    { 
        static void Main(string[] args) 
        { 
            var query = new CustomerQuery(new ProductQuery()); 
            var products = query.GetProducts(1); 
        } 
    }
در کلاس ProductQuery، متدی برای دریافت تمامی محصولات مربوط به یک مشتری وجود دارد. در کلاس CustomerQuery نیز یک متد برای دریافت تمامی محصولات مشتری وجود دارد. در این مثال متد GetProducts در کلاس CustomerQuery را می‌توان «متد حسود» نیز نامید. این نوع استفاده از متد، «الگوی دلال» نیز است. زمانیکه تمامی متدهای یک کلاس به این صورت باشند، آن کلاس به عنوان دلال شناخته می‌شود.

چرا چنین بویی به راه می‌افتد  

معمولا به چند دلیل با این کد بد بو مواجه خواهیم شد: 
  • انتقال مسئولیت‌های یک کلاس به کلاسی دیگر به مرور زمان و تبدیل متدهای آن به هدایت کنندگان فراخوانی.
  • عدم تشخیص درست مسئولیت‌های یک کلاس و اجبار به افزودن هدایت کنندگان فراخوانی در کلاس‌های دیگر. این حالت معمولا زمانی اتفاق می‌افتد که یک کلاس، مسئولیت‌های زیادی داشته باشد و کلاس‌های مختلف، صرفا نیاز به هدایت فراخوانی به این کلاس را داشته باشند. 
  • عدم استفاده مناسب از الگوهای طراحی. 


روش‌های اصلاح این کد بد بو  

روش کلی برای اصلاح چنین بوی بدی، حذف متدها و کلاسهای هدایت کننده فراخوانی و تغییر تمامی استفاده کنندگان از آن‌ها است. در مثال بالا می‌توان متد GetProducts از کلاس CustomerQuery را حذف و تمامی فراخوانی‌های آن را به متد GetProductsByCustomerId از کلاس ProductQuery انتقال داد، یا بلعکس.

چه کدهایی دلال نیستند 

زمانیکه کلاس هدایت کننده فرخوانی به صورت عمدی ساخته شده باشد، معمولا با چنین الگویی روبرو نیستیم. مانند استفاده از الگوهای طراحی زیر: 
  • Chain of responsibility 
  • Decorator 
  • Proxy 
  • Adapter 
هر کدام از الگوهای طراحی ذکر شده در بالا به دلایل خاصی ایجاد می‌شوند و علارغم شباهت زیاد آن‌ها با کد بد بوی دلال، شرایط مربوط به کد بد بود را دارا نمی‌باشند و معمولا نیازی به اعمال تغییری در آن‌ها نیست. با مطالعه و بررسی دقیق الگوهای طراحی می‌توان از تشخیص اشتباه این الگوی بد جلوگیری کرد.  
مطالب
بررسی Bad code smell ها: متد حسود یا Feature envy
متد حسود یا Feature envy در دسته بندی «کدهایی بیش از اندازه، وابسته به هم» قرار می‌گیرد. چنین متدی بیش از آنکه از فیلدها و خصوصیات کلاس خود استفاده کند، از فیلدها و خصوصیات شیء دیگری از نوعی دیگر، استفاده می‌کند.  
یکی از اشکالات کدهای بیش از اندازه وابسته به هم، دشواری در نگهداری و تغییر کد است. به‌طوری‌که در زمان تغییر بخشی از کد، نیاز است بخش‌های مرتبط نیز مورد بررسی قرار گیرند. همچنین وابستگی بیش از اندازه کلاس‌ها به یکدیگر قابلیت جداسازی و استفاده مجدد کلاس‌ها را کاهش خواهد داد.
معمولا در نتیجه‌ی جابجایی مسئولیت‌ها، در بخش‌های مختلف کد، شاهد چنین کد بد بویی هستیم. یکی از پر تکرارترین شرایط، زمانی است که تعدادی از متغیرهای متد، به کلاس داده خاص خود منتقل شوند.
 به طور مثال: 
در این کد یک کلاس برای ایجاد یک آیتم صورت حساب نوشته شده است که یک آیتم از قرارداد را به عنوان ورودی دریافت و سپس اقدام به ایجاد یک آیتم صورت حساب می‌کند.
public class OrderItem 
{ 
    public int Quantity { get; set; } 
    public decimal UnitPrice { get; set; } 
    public decimal Discount { get; set; } 
} 
public class InvoiceItemGenerator 
{ 
    private readonly OrderItem _orderItem; 
    public InvoiceItemGenerator(OrderItem orderItem) 
    { 
        _orderItem = orderItem; 
    } 
    public dynamic Generate() 
    { 
        dynamic invoiceItem = new ExpandoObject(); 
        invoiceItem.Amount = _orderItem.Quantity * _orderItem.UnitPrice - _orderItem.Discount; 
        return invoiceItem; 
    } 
}
اگر به متد Generate دقت کرده باشید متوجه خواهید شد که این متد از خصوصیات شی OrderItem استفاده بیش از اندازه می‌کند و در حال انجام محاسبه‌ای است که ظاهرا بهتر بود جای دیگری باشد.  
در این مثال خاص دو راه حل برای این موضوع وجود دارد: 
اول: انتقال منطق محاسبه مبلغ نهایی آیتم، به کلاس OrderItem. مانند:
public class OrderItem 
{ 
    public int Quantity { get; set; } 
    public decimal UnitPrice { get; set; } 
    public decimal Discount { get; set; } 
    public decimal GetFinalAmount() 
    { 
        return Quantity * UnitPrice - Discount; 
    } 
} 
public class InvoiceItemGenerator 
{ 
    private readonly OrderItem _orderItem; 
    public InvoiceItemGenerator(OrderItem orderItem) 
    { 
        _orderItem = orderItem; 
    } 
    public dynamic Generate() 
    { 
        dynamic invoiceItem = new ExpandoObject(); 
        invoiceItem.Amount = _orderItem.GetFinalAmount(); 
        return invoiceItem; 
    } 
}
دوم: انقال کل منطق محاسبه قیمت به کلاسی مثلا با نام InvoiceItemAmountCalculator که در نوشته‌های پیشین نمونه‌ای از آن را مشاهده کردیم. در واقع در این روش استراتژی محاسبه قیمت را به صورت کلاسی مجزا پیاده سازی می‌کنیم. 
به طور کلی روش‌های رفع چنین بوی بدی به همین دو نوع برخورد ختم خواهد شد. ایجاد یک کلاس استراتژی از نظر اصل Single responsibility مفید است؛ ولی ممکن است کد را در دام «درخت ارث بری موازی» بیندازد. 

جمع بندی 

این کد بد بو نیز یکی از پرتکرارترین کدهای بد بوی قابل مشاهده در پروژه‌های نرم افزاری است. یکی از نتایج مستقیم این کد بد بو، وجود کدهای تکراری فراوان برای انجام روال‌های تقریبا یکسان است که با رفع این بو به خوبی برطرف می‌شوند. همچنین رفع این بوی بد به افزایش قابلیت نگهداری کد نیز کمک بسیار زیادی می‌کند. 
مطالب
نگاهی به مزایا و معایب Xamarin.Android
حجم Package نهایی Xamarin.Android:
Xamarin هنگام ایجاد Package برنامه، روش‌های مختلفی را برای کاهش حجم آن به کار می‌برد که البته این روش‌ها همراه با حفظ کارآیی برنامه در حالت‌های Debug و Release می‌باشد.
یک برنامه‌ی Xamarin برای اجرا باید شامل: برنامه‌ی ما، کتابحانه‌های ارتباطی، محتویات، Mono runtime، اسمبلی‌های (BCL(Base Class Library باشد. برای مثال اگر شما همان مثال پیش فرض Hello work را که با ساخت Solution جدید ایجاد می‌شود، در نظر بگیرید، Package کامل آن بعد از ایجاد (build) به صورت زیر است:



واقعیت این هست که برای چنین برنامه‌ی کوچکی، 15مگابایت حجم زیادی به حساب می‌آید. بیشتر این حجم به دلیل کتابخانه‌ی کلاس‌های پایه (BCL) می‌باشد که شامل mscorlib.lib، system و Mono.Android هستند. این کلاس‌ها کامپوننت‌هایی را که برنامه‌ی ما برای اجرا به آن‌ها احتیاج دارند، فراهم می‌کنند. البته واقعیت این است که برنامه‌ی ما از تمام این امکانات استفاده نمی‌کند و می‌توان از خیلی از آن‌ها صرف نظر کرد.

وقتی شما برنامه‌ای را برای توزیع آماده می‌کنید، Xamarin پروسه‌ای را که به Linking معروف است، اجرا می‌کند. در این پروسه کدهایی که استفاده نشده‌اند حذف می‌شوند. به این ترتیب حجم کدهای برنامه را کاهش می‌دهند. در واقع بخش‌هایی از BCL را که استفاده نکرده‌ایم از Package نهایی حذف می‌کند. برای مثال پروژه‌ی "Hello Word"را در نظر بگیرید (پروژه‌ی پیش فرض). به دلیل آنکه ما از کلاس‌های خاصی استفاده نکرده‌ایم، مقدار زیادی از کدهای بلااستفاده‌ی BCL حذف می‌شوند. تصویر زیر حجم برنامه را مشخص می‌کند:



چه زمانی از Xamarin.Forms استفاده کنیم:

یکی از راه‌های ایجاد برنامه‌های بومی برای اندروید و iOS، استفاده از Xamarn.Android و Xamarin.iOS است. راه دیگر آن Xamarin.Forms است که بیشترین قابلیت اشتراک UI را دارا می‌باشد. در Xamarin.Forms ما می‌توانیم از XAML برای ایجاد UI استفاده کنیم. اما کی بهتر است از آن استفاده کنیم و چه وقت خوب نیست؟

مواردی که بهتر است از Xamarin.Forms استفاده کنیم:

  • برنامه‌های ورود اطلاعات (ِData Entry)
  • ایجاد نمونه‌های اولیه
  • برنامه‌هایی که به بازه‌ی وسیعی از قابلیت‌های بومی دستگاه مورد نظر احتیاج ندارد.
  • برنامه‌هایی که اشتراک کد برای ما مهمتر از نمای ظاهری و زیبایی برنامه باشد.


مواردی که بهتر است از Xamarin.Forms استفاده نکنیم

  • برنامه هایی که تعامل زیادی با کاربر دارد.
  • تهیه‌ی برنامه‌هایی با ظاهر بسیار زیبا و پر رنگ و لعاب!
  • برنامه‌هایی که نیاز به استفاده‌ی از بازه‌ی وسیعی از API‌های بومی را دارند.
  • برنامه هایی که در آن‌ها UIهای سفارشی مهم‌تر از اشتراک کد می‌باشند.
مطالب
تبادل داده‌ها بین لایه‌ها؛ قسمت آخر

روش سوم: DTO (Data transfer objects) 

در قسمت‌های قبلی دو روش از روش‌های موجود جهت تبادل داده‌ها بین لایه‌ها، ذکر گردید و علاوه بر این، مزایا و معایب هر کدام از آنها نیز ذکر شد. در این قسمت دو روش دیگر، به همراه مزایا و معایب آنها برشمرده می‌شود. لازم به ذکر است هر کدام از این روش‌ها می‌تواند با توجه به شرایط موجود و نظر طراح نرم افزار، دارای تغییراتی جهت رسیدن به یکسری اهداف و فاکتور‌ها در نرم افزار باشد. 

در این روش ما سعی می‌کنیم طراحی کلاس‌ها را به اصطلاح مسطح ( flatten) کنیم تا بر مشکل double loop که در قسمت قبل بحث کردیم غلبه کنیم. در کد ذیل مشاهده می‌کنید که چگونه کلاس CusomerDTO از CustomerEntity ،  مشتق می‌شود و کلاس Address را با CustomerEntity ادغام می‌کند؛ تا برای افزایش سرعت لود و نمایش داده‌ها، یک کلاس de-normalized شده ایجاد نماید. 

public class CustomerDTO : CustomerEntity 
{
    public AddressEntity _Address = new AddressEntity();
}

در کد ذیل می‌توانید مشاهده کنید که چگونه با استفاده از فقط یک loop یک کلاس de-normalized شده را پر می‌کنیم. 

foreach (DataRow o1 in oCustomers.Tables[0].Rows)
{
CustomerDTO o = new CustomerDTO();
o.CustomerCode = o1[0].ToString();
o.CustomerName = o1[1].ToString();
o._Address.Address1 =  o1[2].ToString();
o._Address.Address2 = o1[3].ToString();
obj.Add(o);
}

UI هم به راحتی می‌تواند DTO را فراخوانی کرده و دیتا را دریافت کند.


مزایا و معایب روش DTO 

یکی از بزرگترین مزایای این روش سرعت زیاد در بارگذاری اطلاعات، به دلیل استفاده کردن از ساختار de-normalized می‌باشد. اما همین مسئله خود یک عیب محسوب می‌شود؛ به این دلیل که اصول شئ گرایی را نقض می‌کند.


روش چهارم: Hybrid approach (Entity + DTO) 

از یک طرف کلاس‌های Entity که دنیای واقعی را مدل خواهند کرد و همچنین اصول شئ گرایی را رعایت می‌کنند و از یک طرف دیگر DTO نیز یک ساختار flatten را برای رسیدن به اهداف  کارآیی دنبال خواهند کرد. خوب، به نظر می‌رسد که بهترین کار استفاده از هر دو روش و مزایای آن روش‌ها باشد. 

زمانیکه سیستم، اهدافی مانند انجام اعمال CRUD را دنبال می‌کند و شما می‌خواهید مطمئن شوید که اطلاعات، دارای integrity می‌باشند و یا اینکه می‌خواهید این ساختار را مستقیما به کاربر نهایی ارائه دهید، استفاده کردن از روش (Entity) به عنوان یک روش normalized می‌تواند بهترین روش باشد. اما اگر می‌خواهید حجم بزرگی از دیتا را نمایش دهید، مانند گزارشات طولانی، بنابراین استفاده از  روش DTO با توجه به اینکه یک روش de-normalized به شمار می‌رود بهترین روش می‌باشد.


کدام روش بهتر است؟

Non-uniform : این روش برای حالتی است که متد‌های مربوط به data access تغییرات زیادی را تجربه نخواهند کرد. به عبارت دیگر، اگر پروژه‌ی شما در آینده دیتابیس‌های مختلفی را مبتنی بر تکنولوژی‌های متفاوت، لازم نیست پشتیبانی کند، این روش می‌تواند بهترین روش باشد.

Uniform : Entity, DTO, or hybrid : اگر امکان دارد که پروژه‌ی شما با انواع مختلف دیتابیس‌ها مانند Oracle و Postgres ارتباط برقرار کند، استفاده کردن از این روش پیشنهاد می‌شود.   
مطالب
SASS #1

SASS چیست؟

SASS مخفف Syntactically Awesome Style Sheets است که توسط آقای Hampton Catlin طراحی و ایجاد شده است و همانند CoffeeScript که پس از کامپایل به جاوااسکریپت تبدیل می‌شد، SASS نیز پس از کامپایل به CSS تبدیل می‌شود. SASS با استفاده از متغیرها، mixins، ارث بری و قوانین تودرتو، CSS را با مهارت زیادی در بهترین حالت تولید می‌کند.

SASS باعث کمتر نوشتن کد CSS، سبب افزایش خوانایی و دستکاری کردن راحتتر و پویای آن می‌شود. این مساله راهی عالی برای نوشتن کدهای CSS کاربردی‌تر است و می‌تواند سرعت گردش کار هر توسعه دهنده و یا طراح وب را افزایش دهد.

وقتی اولین بار SASS عرضه شد، syntax آن تفاوت قابل توجهی با CSS داشت (پسوند فایل‌های آن SASS. است) که به جای نوشتن براکت‌ها، از تورفتگی استفاده می‌شد و دیگر نیازی به نوشتن ";" نبود. البته با عدم استقبال از این syntax مواجه شد و با عرضه‌ی نسخه 3 SASS، (که پسوند فایل‌های آن SCSS. است) syntax آن بسیار شبیه به CSS شد؛ البته با همه‌ی ویژگی‌های SASS.

برای مثال کد CSS زیر را می‌خواهیم به دو روش بنویسیم:

header {
     margin: 0;
     padding: 0;
     color: #fff;
}
با استفاده از روش SCSS. (روش جدید)
$color:  #fff;
header {
    margin: 0;
    padding:0;
    color: $color;
}
با استفاده از روش SASS. (روش قدیم)
$color: #fff
header
   margin: 0
   padding: 0
   color: $color
همانطور که مشاهده می‌کنید برای نوشتن مقدار color از متغیر color$ استفاده کردیم . در ادامه به قابلیت‌های SASS خواهیم پرداخت.

توجه: syntax ایی که در این سری آموزشی با آن کار می‌کنیم SCSS. است.

کامپایل کردن SASS

روش‌های مختلفی برای کامپایل فایل‌های SASS وجود دارند:
  • روش اصلی استفاده از SASS در Ruby است که پس از نصب Ruby و اجرای فرمان SASS ،gem install sass نصب می‌شود و برای کامپایل، اجرای فرمان زیر:
sass myfile.scss myfile.css
  • استفاده از برنامه‌های گرافیکی مانند Hammer , CodeKit و Compass.
  • استفاده از برنامه‌های رایگان مانند libsass که با یک کامپایلر سریع نوشته شده با ++C/C است و همچنین می‌توانید libsass را از طریق NPM با node-sass   نصب کنید.
npm install node-sass
نکته: در صورتیکه می‌خواهید با استفاده از Ruby کار کامپایل را انجام دهید در هنگام نصب Ruby گزینه‌ی "Add Ruby executables to your PATH" را تیک بزنید.

خب سوالی که ممکن است برای شما پیش آمده باشد این است که باید از کدام یک از این روش‌ها را استفاده کنیم؟
بستگی به این دارد که شما چه کاری را می‌خواهید انجام دهید.
  • در صورتیکه بر روی یک پروژه‌ی بزرگ با میزان کد زیاد کار می‌کنید، استفاده از Ruby SASS، کمی کند کار کامپایل را انجام می‌دهد.
  • اگر بخواهید از libsass استفاده کنید، این مسئله وجود دارد که به طور %100 با قابلیت‌های Ruby SASS برابری ندارد.
  • در صورتیکه نمی‌خواهید از command line استفاده کنید، برنامه‌های گرافیکی گزینه‌ای عالی هستند. شما می‌توانید طوری تنظیم کنید که تمامی تغییراتی که در فایل SASS انجام می‌شود، به صورت خودکار کار کامپایل انجام شود.
  • اگر هم فقط می‌خواهید کدی را که نوشته‌اید تست کنید، می‌توانید از ابزارهای آنلاین مانند SassMeister استفاده کنید.