🍁وقتی که توی یه web cotroller همه دپندسی ها رو به کانستراکتور inject میکنیم، همه چیز خوشکل و گوگولی به نظر میاد. ولی ممکنه بعضی از action ها از بعضی دپندنسی ها استفاده نکنن.

👈برای مثال توی کلاس CustomersController چند تا متد زیر رو داشته باشیم:

✔️Search
✔️GetById
✔️Add
✔️EditPersonalInfo
✔️Remove

دپندنسی هایی که هر کدوم از این اکشن متد ها نیاز دارن ممکنه متفاوت باشه.

❓حالا اگه همه دپندنسی ها رو به کانستراکتور inject کنیم چه اتفاقی میوفته؟

فرض میکنیم دپندسی ها scoped یا Transient باشن...

😱هر بار که یه رکوئست جدید میاد یه نمونه ی جدید از کنترلر با تمام دپندسی هاش ساخته میشه، در حالیکه بعضی از اون دپندسی ها مورد استفاده ی اون اکشن متدی که قراره رکوئست رو هندل کنه قرار نمیگیرن.

😱😱حالا خود اون دپندسی ها هم هر کدومشون ممکنه چنتا دپندسی دیگه داشته باشن!!!

پس توی هر رکوئست چندین تا دپندنسی ساخته میشه که اصلن به کار نمیان!!!

🙄پرفرمنس رو دریاب نه خوشکلی!!!

❓راه حل چیه؟

✅اینجاست که inject کردن دپندسی ها به متد به جای کانستراکتور راه حل بهتریه.

🔥اون دپندسی هایی که توسط همه ی متد ها استفاده میشن رو به کانستراکتور inject میکنیم و اونهایی که فقط توسط یه متد خاص استفاده میشن رو به همون متد...

هدف کد هم مشخص تر میشه.
به هر حال web cotroller ها کلاس هایی نیستن که خیلی single responsibility داشته باشن.

👈البته فریمورکی که استفاده میکنی باید این رو پشتیبانی کنه.

@purecoder_ir

🔥یک نکته ی کوچیک

public class AuthorDto
{
    [Key]
    public Guid Id {get; set;}

    [Required]
    [MaxLength(50)]
    public string FirstName {get; set;}

    [Required]
    [MaxLength(50)]
    public string LastName {get; set;}

    [Required]
    public DateTimeOffset DateOfBirth {get; set;}

    [Required]
    [MaxLength(50)]
    public string MainCategory {get; set;}

    public ICollection<Course> Courses {get; set;}
        = new List<Course>();

    
}

❌اعمال ولیدیشن به این شکل و با استفاده از Annotation بالای سر پراپرتی های Dto باعث نقض Single Responsibility میشه!!!

✅تنها مسيولیت یا Single Responsibility یک Dto انتقال یا transfer کردن دیتاست و نه چیز دیگه.

❌این مدل ولیدیشن احتمال duplication رو هم بالا میبره که با نقض SRP ارتباط تنگاتنگ داره...

پ.ن: مثال با سی شارپه, ولی این مدل ولیدیشن رایجه و نمونش رو جاهای دیگه هم میتونید ببینید.

@purecoder_ir

این استدلال باب مارتین در رد استفاده از حرف "I" در ابتدای نام اینترفیس هاست...

Interfaces and Implementations

These are sometimes a special case for encodings. For example, say you are building an ABSTRACT FACTORY for the creation of shapes. This factory will be an interface and will be implemented by a concrete class. What should you name them?

IShapeFactory and ShapeFactory?

I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface. I just want them to know that it’s a ShapeFactory. So if I must encode either the interface or the implementation, I choose the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable to encoding the interface.

من بعدن نظرم رو در مورد این استدلال میگم... .

حالا تو بگو که توی نام گذاری اینترفیس ها از حرف "i" استفاده میکنی یا نه؟

@purecoder_ir