نظرات مطالب
آشنایی با NHibernate - قسمت هشتم
حق با شما است. روش صحیح لایه بندی این قسمت بر اساس تعریف unit of work و سپس repository است. یک unit of work می‌تواند از اعمال حاصل چندین repository تشکیل شده و نهایتا در پایان کار همه را یکجا اعمال کند. در مثال فوق این دو مفهوم با هم تلفیق شده.
بنابراین اگر علمی‌تر می‌خواهید کار کنید در مورد unit of work تحقیق کنید (در سایت nhforge.org).
نظرات مطالب
آموزش سیلورلایت 4 - قسمت‌های 1 تا 5
البته دو پروژه سورس باز در سایت codeplex برای نگارش‌های قبل از 4 موجود است:
http://silverlightrtl.codeplex.com
http://persiansilverlight.codeplex.com/
نظرات مطالب
EF Code First #1
البته این مطلب اول هست. در مطالب بعدی در مورد «اعتبارسنجی» بیشتر بحث شده:
  همچنین نیاز است با «رفتار متصل و غیر متصل در EF» آشنا شوید. این مورد در مطلب «کار با کلیدهای اصلی و خارجی در EF Code first» هم بیشتر بحث شده‌است.

تمام این‌ها در مسیر آموزشی EF Code first به ترتیب لیست شده‌اند؛ قسمت‌های «اعتبارسنجی و بررسی استثناءها» و  «ردیابی تغییرات».
مطالب
روش‌های مختلف انجام چند کار به صورت همزمان در C# .NET - قسمت دوم
در قسمت قبل دیدیم که انجام کارهای همزمان، با Objectهایی که به اصطلاح Thread Safe نیستند (مانند DbContext) خروجی چندان جالبی ندارد و برای مثال اگر در یک Service یک DbContext را Inject کنیم (مثلا با Constructor injection) و از آن در متدی استفاده کنیم که آن متد یا با TPL یا RX و ... به صورت چندتایی و همزمان اجرا شود، DbContext به مشکل می‌خورد؛ یعنی نمی‌توان یک وهله از DbContext را بین چند Thread همزمان پردازش موازی، به اشتراک گذاشت.
در کدهای فرضی مثال‌های قسمت قبل، متدی داشتیم با نام DoSomethingWithCustomer که مثلا همان متدی بود که قرار است همزمان اجرا شود. یکی از ساده‌ترین کارهایی که برای رفع این مشکل می‌توان انجام داد، نوشتن چنین کدی است:
public async Task DoSomethingWithCustomer(Customer customer)
{
    using var dbContext = new AppDbContext();

    // ...
}
در این حالت، اگر متد DoSomethingWithCustomer به صورت همزمان اجرا شود، به ازای هر بار اجرا، یک DbContext جدید ساخته میشود؛ پس از یک DbContext مشترک، به صورت همزمان توسط چندین Thread پردازش موازی، استفاده نخواهد شد. ولی مشکل اینجاست که از Dependency Injection برای ساختن DbContext استفاده نشده‌است و ما خودمان، هم new کرده‌ایم و هم Dispose!

این روش ابدا توصیه نمی‌شود؛ برای اینکه Dependency Injection این روزها مسائل خیلی زیادی را مدیریت می‌کند. مثلا DbContext در EF Core وقتی با Dependency Injection ساخته شود، Logging اش هم فعال می‌شود و یا مثلا اگر از متد زیر
services.AddDbContextPool<AppDbContext>();
برای Register کردن DbContext استفاده کرده باشیم، تعدادی DbContext ساخته می‌شود و در پروژه به صورت امن از همان چندتا استفاده می‌شود؛ بجای اینکه Objectها مدام ساخته و از بین برده شوند که این مهم، روی کارآیی تاثیر گذار است.
و یا مثلا برای HttpClient فقط در همین سایت نزدیک به یک دوجین مقاله توضیح داده‌اند که چرا new کردن و Dispose کردن HTTP Client مناسب نیست و بهتر است برای Register کردن HttpClient، از services.AddHttpClient استفاده و از IHttpClientFactory و سایر روشها برای Resolve کردن HttpClient استفاده کنیم که اینها نیز توسط Dependency Injection قابل استفاده هستند. از مسائلی مانند Polly و ... نیز می‌گذریم.
راه حل ایجاد یک Context جدید، تقریبا در تمامی کتابخانه‌های Dependency Injection دیده شده‌است و آن ساختن یک Child Scope است. در ادامه با Microsoft.Extensions.DependencyInjection یک پیاده سازی آن‌را خواهیم داشت؛ ولی مشابه این روش در سایر کتابخانه‌ها همچون Autofac نیز شدنی است.

برای شروع System.IServiceProvider را inject کنید. سپس کد قبلی را به این شکل بنویسید:
(نیاز به ;using Microsoft.Extensions.DependencyInjection در بالای فایل کد است)
public async Task DoSomethingWithCustomer(Customer customer)
{
    using var scope = _serviceProvider.CreateScope();
    var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
    var httpClient = scope.ServiceProvider.GetRequiredService<IHttpClientFactory>().CreateClient();
    // ...
}
در این روش فقط نیاز به using نوشتن برای خط اول است؛ یعنی scope که Dispose شود، Objectهایی که به وسیله آن scope ساخته شده‌اند، آزاد خواهند شد. تمام آن چیزهایی را که قبلا با Constructor یا Property injection می‌توانستید بگیرید را اکنون می‌توانید با متد GetRequiredService بگیرید.
همچنین می‌توانید برای داشتن کدی بهتر، یک interface و class را ایجاد کنید و logic مربوطه را در آن سرویس قرار دهید و در آن سرویس با constructor یا property injection از DbContext و HttpClient و سایر سرویس‌ها استفاده کنید و در نهایت آن interface/class را رجیستر کنید و در DoSomethingWithCustomer به کمک child scope، یک object از آن سرویس بسازید و متدش را فراخوانی کنید. برای مثال اگر هدف ساختن Excel تاریخچه خریدهای مشتری است، داریم:
public interface IOrderHistoryService
{
    Task BuildCustomerHistory();
}

public class OrderHistoryService : IOrderHistoryService
{
    private AppDbContext _dbContext;

    public OrderHistoryService(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task BuildCustomerHistory()
    {
        // ...
    }
}
سپس اگر جایی لازم شد روی لیستی از مشتری‌ها این متد اجرا شود، از TPL استفاده می‌کنیم و متدی را فراخوانی می‌کنیم که در آن child scope می‌سازیم و scope.GetRequiredService را برای گرفتن IOrderHistoryService استفاده می‌کنیم. در این روش هم مشکلی در استفاده از Object هایی که thread safe نیستند (مانند DbContext) رخ نخواهد داد و از Dependency injection و مزیت‌های بی‌شمار آن نیز بهره برده‌ایم.
مطالب
کوئری هایی با قابلیت استفاده ی مجدد
با توجه به اصل Dry تا می‌توان باید از نوشتن کدهای تکراری خودداری کرد و کد‌ها را تا جایی که ممکن است به قسمت هایی با قابلیت استفاده‌ی مجدد تبدیل کرد. حین کار کردن با ORM‌های معروف مثل NHibernate و EntityFramework زمان زیادی نوشتن کوئری‌ها جهت واکشی داده‌ها از دیتابیس صرف می‌شود. اگر بتوان کوئری هایی با قابلیت استفاده‌ی مجدد نوشت علاوه بر کاهش زمان توسعه قابلیت هایی قدرتمندی مانند زنجیر کردن کوئری‌ها به دنبال هم به دست می‌آید. 
با یک مثال نحوه‌ی نوشتن و مزایای کوئری با قابلیت استفاده‌ی مجدد را بررسی می‌کنیم : 
برای مثال دو جدول شهر‌ها و دانش آموزان را درنظر بگیرید:
namespace ReUsableQueries.Model
{
    public class Student
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }
    [ForeignKey("BornInCityId")]
        public virtual City BornInCity { get; set; }
        public int BornInCityId { get; set; }
    }

    public class City
    {
        public int Id { get; set; }
        public string Name { get; set; }

        public virtual ICollection<Student> Students { get; set; }
    }
}
در ادامه این کلاس‌ها را در معرض دید EF Code first قرار داده:
using System.Data.Entity;
using ReUsableQueries.Model;

namespace ReUsableQueries.DAL
{
    public class MyContext : DbContext
    {
        public DbSet<City> Cities { get; set; }
        public DbSet<Student> Students { get; set; }
    }
}

و همچنین تعدادی رکورد آغازین را نیز به جداول مرتبط اضافه می‌کنیم:
    public class Configuration : DbMigrationsConfiguration<MyContext>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
        }
        protected override void Seed(MyContext context)
        {
            var city1 = new City { Name = "city-1" };
            var city2 = new City { Name = "city-2" };
            context.Cities.Add(city1);
            context.Cities.Add(city2);
            var student1 = new Student() {Name = "Shaahin",LastName = "Kiassat",Age=22,BornInCity = city1};
            var student2 = new Student() { Name = "Mehdi", LastName = "Farzad", Age = 31, BornInCity = city1 };
            var student3 = new Student() { Name = "James", LastName = "Hetfield", Age = 49, BornInCity = city2 };
            context.Students.Add(student1);
            context.Students.Add(student2);
            context.Students.Add(student3);
            base.Seed(context);
        }
    }
فرض کنید قرار است یک کوئری نوشته شود که در جدول دانش آموزان بر اساس نام ، نام خانوادگی و سن جستجو کند : 
         var context = new MyContext();
          var query= context.Students.Where(x => x.Name.Contains(name)).Where(x => x.LastName.Contains(lastName)).Where(
              x => x.Age == age);
احتمالا هنوز کسانی هستند که فکر می‌کنند کوئری‌های LINQ همان لحظه که تعریف می‌شوند اجرا می‌شوند اما اینگونه نیست . در واقع این کوئری فقط یک Expression از رکورد‌های جستجو شده است و تا زمانی که متد ToList یا ToArray روی آن اجرا نشود هیچ داده ای برگردانده نمی‌شود.
در یک برنامه‌ی واقعی داده‌های باید به صورت صفحه بندی شده و مرتب شده برگردانده شود پس کوئری به این صورت خواهد بود : 
        var query= context.Students.Where(x => x.Name.Contains(name)).Where(x => x.LastName.Contains(lastName)).Where(
              x => x.Age == age).OrderBy(x=>x.LastName).Skip(skip).Take(take);
ممکن است بخواهیم در متد دیگری در لیست دانش آموزان بر اساس نام ، نام خانوادگی ، سن و شهر جستجو کنیم و سپس خروجی را اینبار بر اساس سن مرتب کرده و صفحه بندی نکنیم:
          var query = context.Students.Where(x => x.Name.Contains(name)).Where(x => x.LastName.Contains(lastName)).Where
              (
                  x => x.Age == age).Where(x => x.BornInCityId == 1).OrderBy(x => x.Age);
همانطور که می‌بینید قسمت هایی از این کوئری با کوئری هایی که قبلا نوشتیم یکی است ، همچنین حتی ممکن است در قسمت دیگری از برنامه نتیجه‌ی همین کوئری را به صورت صفحه بندی شده لازم داشته باشیم.
اکنون نوشتن این کوئری‌ها میان کد های Business Logic باعث شده هیچ استفاده‌ی مجددی نتوانیم از این کوئری‌ها داشته باشیم. حال بررسی می‌کنیم که چگونه می‌توان کوئری هایی با قابلیت استفاده‌ی مجدد نوشت : 
namespace ReUsableQueries.Quries
{
    public static class StudentQueryExtension
    {
        public static IQueryable<Student> FindStudentsByName(this IQueryable<Student> students,string name)
        {
            return students.Where(x => x.Name.Contains(name));
        }
        public static IQueryable<Student> FindStudentsByLastName(this IQueryable<Student> students, string lastName)
        {
            return students.Where(x => x.LastName.Contains(lastName));
        }
        public static IQueryable<Student> SkipAndTake(this IQueryable<Student> students, int skip , int take)
        {
            return students.Skip(skip).Take(take);
        }
        public static IQueryable<Student> OrderByAge(this IQueryable<Student> students)
        {
            return students.OrderBy(x=>x.Age);
        }
    }
}
همان طور که مشاهده می‌کنید به کمک متد‌های الحاقی برای شیء IQueryable<Student> چند کوئری نوشته ایم . اکنون در محل استفاده از کوئری‌ها می‌توان این کوئری‌ها را به راحتی به هم زنجیر کرد. همچنین اگر روزی قرار شد منطق یکی از کوئری‌ها عوض شود با عوض کردن آن در یک قسمت برنامه همه جا اعمال می‌شود.  نحوه‌ی استفاده از این متدهای الحاقی به این صورت خواهد بود : 
     var query = context.Students.FindStudentsByName(name).FindStudentsByLastName(lastName).SkipAndTake(skip,take);          
فرض کنید قرار است یک سیستم جستجوی پیشرفته به برنامه اضافه شود که بر اساس شرط‌های مختلف باید یک شرط در کوئری اعمال شود یا نشود ، به کمک این طراحی جدید به راحتی می‌توان بر اساس شرط‌های مختلف یک کوئری را اعمال کرد یا نکرد : 
        var query = context.Students.AsQueryable();
          if (searchByName)
          {
              query= query.FindStudentsByName(name);
          }
          if (orderByAge)
          {
              query = query.OrderByAge();
          }
          if (paging)
          {
             query =  query.SkipAndTake(skip, take);
          }
          return query.ToList();
همچنین این کوئری‌ها وابسته به ORM خاصی نیستند البته این نکته هم مد نظر است که LINQ Provider بعضی ORM‌ها ممکن است بعضی کوئری‌ها را پشتیبانی نکند.

بازخوردهای پروژه‌ها
نحوه جستجو
سلام جناب نصیری
در صورت امکان در مورد نحوه جستجو در سایت و یا در یک بسته نرم افزاری توضیحاتی ارائه بدید.
سیستم جستجوی جدید با قابلیت پیشنهاد به کاربر سایت خودتون رو هم لطف کنید به صورت یک مقاله در صورت صلاحدید توضیح بدید.
با تشکر
مسیرراه‌ها
آزمون واحد در دات نت
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت اول
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت دوم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت سوم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت چهارم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت پنجم
آشنایی با آزمایش واحد (unit testing) در دات نت قسمت ششم

آشنایی با mocking frameworks - قسمت اول
آشنایی با mocking frameworks - قسمت دوم

چگونه کد قابل تست بنویسیم - قسمت اول
چگونه کد قابل تست بنویسیم - قسمت دوم

Test Driven Development

Microsoft Test Manager 

نوشتن آزمون‌های واحد به کمک کتابخانه‌ی Moq  

دیگر مقالات
مطالب
آشنایی با Oslo - قسمت اول

Oslo پلتفرم جدید مدل‌سازی مایکروسافت است که در سال‌های آتی مورد استفاده قرار خواهد گرفت و همچنین این روزها در مجامع توسعه و طراحی برنامه‌ها به شدت مورد بحث و توجه است. به همین جهت در طی مقالاتی با این پلتفرم جدید بیشتر آشنا خواهیم شد.

دریافت Oslo

Oslo از سه قسمت عمده تشکیل شده است:
  • الف) زبان مدل سازی M
  • ب) ابزار مدل سازی Quadrant
  • ج) استفاده از SQL Server به عنوان مخزن

زبان مدل سازی M از سه قسمت به نام‌های MGraph ، MGrammer و MSchema تشکیل می‌شود.
MGrammer : گرامر مورد استفاده در SDL را تعریف می‌کند. Syntax Directed Translation
MSchema : طرح مدل را تعریف خواهد کرد.
MGraph : اگر MSchema بیانگر انواع باشد، MGraph بیانگر وهله‌ها خواهد بود.

یک مثال:
برنامه‌ی Intellipad را اجرا کنید (فرض بر این است که SDK فوق را نصب کرده‌اید)



در اینجا حالت را بر روی M Mode قرار دهید (مطابق تصویر) و همچنین از منوی ظاهر شده‌ی M Mode ، گزینه‌ی Generic T-SQL preview را هم انتخاب کنید.

اولین ماژول ما به صورت زیر است:

module Test1
{
type ApplicationUser
{
UserID : Integer64=AutoNumber();
FirstName :Text#15;
LastName : Text#25;
Password : Text#10;
} where identity UserID;
}

ابتدا نام ماژول مشخص می‌شود. شبیه به معرفی یک فضای نام در برگیرنده‌ی اشیای مربوطه. سپس type ، بیانگر همان MSchema خواهد بود.
در این مثال شناسه‌ی کاربری از نوع Integer64 خود افزایش یابنده تعریف شده است (نوع identity در اس کیوال سرور).
فیلدهای نام ، نام خانوادگی و کلمه‌ی عبور از نوع متنی با اندازه‌های مشخص 15 ، 25 و 10 کاراکتر تعریف شده‌اند. اگر اندازه مشخص نبود نوع را تنها Text تعریف کنید.
نکته:
1-اگر پس از Text علامت ? قرار گیرد، به معنای فیلدی از نوع nullable خواهد بود و برعکس. زیبایی Intellipad هم در اینجا است که بلافاصله پس از تایپ شما، عبارت T-SQL معادل را تولید می‌کند.
2-در اینجا UserID‌ به صورت identity معرفی شده است. در زبان ام ، identity همانند primary key‌ در عبارات T-SQL عمل می‌کند و نباید اشتباه گرفته شود.

تا اینجا فقط یک type تعریف شده است. برای تبدیل آن به یک جدول باید آن‌را توسعه داد.

ApplicationUserCollection : ApplicationUser*;

این سطر را به پس از تعریف type اضافه نمائید. علامت ستاره در اینجا به معنای صفر یا بیشتر است و جهت بسط نوع تعریف شده به یک مجموعه به کار می‌رود. اکنون با اضافه شدن این سطر، Intellipad بلافاصله عبارات T-SQL معادل را تولید خواهد کرد که در تصویر مشخص است. به این صورت MGraph ما که بیانگر وهله‌هایی از نوع ApplicationUser هستند تولید گردید.

اکنون قصد داریم گروهی از کاربرها را به صورت نمونه ایجاد کنیم:

ApplicationUserCollection
{
//using a named instance
User1 {
FirstName="user1",
LastName="name1",
Password="1@34"
},
User2 {
FirstName="user2",
LastName="name2",
Password="123@4"
},
User3 {
FirstName="user3",
LastName="name3",
Password="56#2"
},
User4 {
FirstName="user4",
LastName="name4",
Password="789@5"
}
}

سطرهای فوق را پس از تعریف ApplicationUserCollection در Intellipad اضافه کنید. بلافاصله Intellipad عبارات T-SQL معادل را برای ما تولید خواهد کرد.



ادامه دارد ...

مطالب
استفاده از واژه‌نامه آنلاین babylon در فایرفاکس

مطلبی را امروز در حین جستجو در سایت اسکریپت‌های گریس مانکی دیدم که محض اطلاعات عمومی بد نیست :)

ابتدا گریس مانکی را نصب کنید :)
https://addons.mozilla.org/en-US/firefox/addon/748
یکبار فایرفاکس را ببندید و باز کنید.
اکنون به آدرس زیر رفته و بر روی دکمه install this script در بالای صفحه کلیک کنید:
http://userscripts.org/scripts/show/9671
بعد از نصب آن، به آدرس زیر مراجعه کنید و همین عملیات را تکرار کنید یعنی install this script
http://userscripts.org/scripts/show/36230
خوب، الان دکمه F4 را فشار دهید. یک صفحه مشکی در پائین صفحه باز خواهد شد. (با فشردن مجدد F4 حذف خواهد شد)
تذکر: اگر با فشردن دکمه F4 تغییری را مشاهده نکردید، یکبار فایرفاکس را ببندید و باز کنید تا اسکریپت‌ها کاملا بارگذاری شوند.
بر روی babylon.persian کلیک کنید تا زرد شود (فعال شود)
اکنون بر روی هر کلمه‌ای در صفحه دوبار کلیک کنید تا انتخاب شود، بلافاصله معنای فارسی آنرا در پائین صفحه خواهید دید.

شایان ذکر است که نیازی به نصب babylon نیست و مستقل عمل می‌کند.

نکته: برای زیاد کردن ارتفاع آن بر روی فلش به سمت بالا کلیک کنید، ماوس را نگه داشته و به سمت بالا حرکت دهید (یا برعکس به سمت پائین)




اسکریپت‌های جالبی را با گریس مانکی بر روی فایرفاکس اجرا می‌کنند. (اگر لینک‌های سایت رو پیگیری کرده باشید تشخیص سالم بودن لینک‌های رپید شیر در یک صفحه واقعا کارآمد بود و نمونه‌های بی‌شماری که در سایت اسکریپت‌های آن می‌توانید پیدا کنید یا از آنها ایده بگیرید)

نظرات مطالب
اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity
با سلام؛ خیلی معماری جالبی بود. اما یه سوالی ذهن مرا مشغول کرده . البته من ساختار structureMap را درست نمی‌دانم ولی اکثر IOC Container‌ها نمونه singlethon  را از اینترفیس‌ها برمی گردانند . که اگر اینگونه باشد به معنی وجود یک Unit OF Work و DbContext بوده در کل appllication بوده که این برای یک وب اپلیکیشن به منزله یک فاجعه است. اگر ممکن است مقداری راهنمایی بفرمایید. سپاسگزارم.