بسیار ممنون از شما بابت این مقاله
چند پیشنهاد داشتم :
1 - در مورد  Railway-oriented Programming   مقاله جداگانه تهیه شود.
2- برای تکمیل این بخش مطلبی در مورد  Either   تهیه شود. برای اطلاع بیشتر
3- استفاده از لایه Service باعث نقض قانون  encapsulation شده و بهتر است در برنامه‌های بزرگ از آن به این طریق استفاده نشود زیرا باعث complex و discovery کد و درنهایت بروز خطا در برنامه خواهد شد. مانند:
namespace EF_Sample07.DomainClasses
{
    public class Product
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public decimal Price { get; set; }
    }
}
namespace EF_Sample07.ServiceLayer
{
    public interface IProductService
    {
        void AddNewProduct(Product product);
    }
}
برای حل این مشکل باید از immutable ، value object  و  Shadow Properties کمک  گرفت
namespace EF_Sample07.DomainClasses
{
    public class Product : Entity
    {
        public Product ( ProductName name, decimal price)
        {
              this.Name=name;
              this.Price = price;
         }  
        private string _name ;
        public ProductName Name { get=> (ProductName)_name;  set=> _ name = value } //value object with Shadow Properties  
        public decimal Price { get;}
        
    }
}

و شاید به دلیل یک سری از دلایل بخواهیم در مدل برنامه قانون encapsulation رو نقض کنیم که اگر با این سناریو مواجه شدیم میتوانیم از مهندس ساخت اشیا یعنی Builder استفاده ببریم.
4- بد نیست جامعه dotnettips این سری از مقاله ها رو به فارسی برگردونه.
 
‫۶ سال و ۱ ماه قبل، پنجشنبه ۴ مرداد ۱۳۹۷، ساعت ۰۰:۴۸
ممنون از شما ...
هدف بنده از این مطلب آشنایی با این ایده (maybe or optional )که شما را به دنیای برنامه نویسی تابعی در#C هدایت کند اون هم با ساده‌ترین روش و مثال بود نه پیاده سازی خاصی چون در طول زمان پیاده سازی‌ها متفاوت خواهند شد ولی مفاهیم ثابت می‌مونن.
این  کتابخانه  و کتابش    هم خوبه اگر دوست داشتید. 
‫۶ سال و ۴ ماه قبل، سه‌شنبه ۱۱ اردیبهشت ۱۳۹۷، ساعت ۰۳:۲۳
یکی از ویژگی‌های جالب Tuple اینه که میشه در بدنه For نوع داده‌ی متفاوتی قرار داد
public static  void Main() 
{
        var li = Enumerable.Range(1, 10).ToList();
        var sb = new StringBuilder();
        //for (int i=0,j=1;;) 
//در اینجا میشه نوع‌های متفاوتی تعریف کرد
        for ( (int i, bool first) = (0, true); i < li.Count; i++, first = false)
        {
            if (!first)
                sb.Append(", ");
            
            sb.Append(li[i]);
        }
        
        Console.WriteLine(sb.ToString());
}
‫۶ سال و ۵ ماه قبل، چهارشنبه ۲۹ فروردین ۱۳۹۷، ساعت ۰۲:۰۶
مثالی از ترکیب C# Using Alias و Static Using 
using Name = System.String;
using Greeting = System.String;
using PersonalizedGreeting = System.String;
using static System.Console; 
namespace Test
{
 private static void Main(string[] args)
        {

        Func<Greeting, Name, PersonalizedGreeting> greet
                = (gr, name) => $"{gr}, {name}";
            Name[] names = { "alireza1", "Alirea2" };
            foreach (var name in names)
            {
                WriteLine(greet("hello", name));
            }
// prints: Hello, alireza1
            // Hello, Alirea2
            
            ReadLine();
        }

}

‫۶ سال و ۵ ماه قبل، پنجشنبه ۹ فروردین ۱۳۹۷، ساعت ۲۱:۱۹
ممنون بابت پاسختون...
اگر لایه Service به عنوان ماژول سطح بالا   فرض کنیم  و لایه DataAccsessLayer رو به عنوان   ماژول سطج پایین  فرض کنیم. مگر طبق تعریف قانون DIP  نباید رابط IUnitOfWork رو در لایه Service تعریف کرده و  لایه DAl موظف باشد ویژگی‌های مورد نیاز Service را  پیاده سازی کند و دیگر لازم نیست applicationDbContext رو به صورت public کنیم و میتوانیم اون رو به صورت internal  تعریف کنیم.

مانند پروژه  eShopOnContainers .


‫۶ سال و ۵ ماه قبل، پنجشنبه ۹ فروردین ۱۳۹۷، ساعت ۱۶:۳۵
درباره این لایه بندی چند سوال برام پیش اومده  :
1-  چرا  اینترفیس IUnitOfWork در لایه Service تعریف نشده و چون به نظر میرسه که ما اینجا اصل( Dependency Inversion Principle (DIP) رو رعایت نکرده ایم.
2- بهتر نبود ِApplicationDbContext  در لایه Infrastructure  تعریف می‌شد؟