مقارنة Mapster وAutoMapper أسرع طريقة للـDTO

إزاي Mapster أو AutoMapper بيوفروا وقتك في الـ DTOs؟
لو اشتغلت في أي مشروع .NET هتلاقي نفسك كل شوية بتعمل نفس الشغل:
كلاس من الـDatabase → يتحول لـDTO
Request من الـFrontend → يتحول لـEntity
وبيفضل الموضوع ده يتكرر ويتكرر لحد ما تحس إنك بقيت عامل زي ماكينة نسخ شغالة طول الوقت.

العملية دي اسمها Mapping، ولما عدد الـEntities و الـDTOs يكتر… هتلاقي إن كتابة الـMapping يدوي بقت حاجة مملة جدًا وممكن يحصل فيها غلطات بسهولة.

هنا بيجي دور أدوات زي AutoMapper و Mapster
دول بيخلوا التحويلات دي تحصل بشكل أوتوماتيك بدل ما تكتبها كل مرة بإيدك.

لكن السؤال المهم:
مين أفضل؟ وإمتى تستخدم ده وإمتى تستخدم ده؟

يلا نفهم بهدوء وبطريقة بسيطة

---

يعني إيه DTO أصلاً؟ ​

الـ DTO (Data Transfer Object) هو object بسيط بنستخدمه علشان ننقل الداتا من مكان لمكان
زي:

• من الـBackend للـFrontend
• من API لـAPI
• من form لـDatabase

مثال بسيط:

public class UserEntity
{
    public int Id { get; set; }
    public string FullName { get; set; }
    public string PasswordHash { get; set; }
}

public class UserDto
{
    public int Id { get; set; }
    public string FullName { get; set; }
}

لو هنبعت UserEntity للـFrontend زي ما هي
الـPasswordHash هيطلع معاه… وده خطر

علشان كده بنستخدم DTO.

---

المشكلة بقى ​

كتابة mapping يدوي ليهم بتكون كده:

var dto = new UserDto
{
    Id = user.Id,
    FullName = user.FullName
};

الموضوع بسيط صح؟
بس تخيل تعمل كده مع 50 موديل و 100 DTO
هتلاقي نفسك غرقان في كود مكرر.

---

AutoMapper: اللاعب القديم الخبير ​

AutoMapper مشهور جدًا وبقاله سنين في السوق.
فكرته إنه يعمل mapping تلقائي بناءً على أسماء الـProperties.

مثال استخدامه:​

var config = new MapperConfiguration(cfg =>
{
    cfg.CreateMap<UserEntity, UserDto>();
});

var mapper = config.CreateMapper();
var dto = mapper.Map<UserDto>(user);

مميزات AutoMapper ​

• Mature ومستقر
• Community كبير
• بيدعم Conditional Mapping
• بيدعم Custom Resolvers
• بيندمج كويس جدًا مع LINQ والـQueries

عيوب AutoMapper ​

• أوقات بيبقى معقد زيادة عن اللزوم
• بيعتمد على Reflection كتير → وده يقلل الأداء في الـLoads الكبيرة
• محتاج Configuration أكتر شوية من Mapster

بصيغة تانية:
هو قوي جدًا… بس أوقات تقيل شوية.

---

Mapster: اللاعب الجديد السريع ​

Mapster أحدث من AutoMapper، وهدفه الأساسي هو السرعة والبساطة.

الفرق إنه بيعمل Compile للـMappings كأنك أنت اللي كتبتها يدوي
وده بيديه أداء أسرع بكتير.

مثال:​

var dto = user.Adapt<UserDto>();

وده كده؟
أيوه… بكل بساطة.

ليه Mapster أسرع؟ ​

علشان بيستخدم Expression Trees ويولد كود حقيقي بدل الـReflection.
يعني بيكتب mapping نيابة عنك.

مميزات Mapster ​

• أسرع من AutoMapper في أغلب الحالات
• سهل الاستخدام جدًا
• API نظيف وبسيط

عيوب Mapster ​

• لسه أحدث، فـ features المتقدمة أقل من AutoMapper شوية
• لو الـMapping معقد، هتحتاج تفهمه كويس

---

طيب… أستخدم مين؟ ​

خلينا نقولها بمثال واقعي:

الحالة	الأفضل
عندك مشروع كبير وفيه Mapping كتير جدًا	Mapster (علشان الأداء)
عندك Mapping معقد وBusiness Rules كتير	AutoMapper (علشان المرونة)
بتشتغل في شركة معظم كودها AutoMapper	كمل AutoMapper
بتبدأ مشروع جديد من الصفر	Mapster هيبقى خيار ممتاز

نقطة مهمة جدًا ​

الـPerformance مش دايمًا هو العامل الأساسي.
آه Mapster أسرع،
بس ده مش معناه إن AutoMapper بطيء لدرجة إنه يبهدل السيرفر.
في 80% من المشاريع… مش هتحس بالفرق أصلاً.

الأهم بكتير هو:

• الكود يبقى واضح
• سهل تتعدل عليه
• تقدر تفهمه بعد سنة من دلوقتي

---

الفرق في الكود ​

AutoMapper Mapping​

cfg.CreateMap<CreateUserRequest, UserEntity>();

Mapster Mapping​

TypeAdapterConfig<CreateUserRequest, UserEntity>.NewConfig();

تحويل​

var user = request.Adapt<UserEntity>();

---

الخلاصة ​

• AutoMapper = قوي + مرن + مستقر
• Mapster = أسرع + أبسط + خفيف

اختار بناءً على نوع مشروعك مش على تريند الناس.

ولو عجبك الموضوع…
ابدأ بتجربة Mapster في مشروع صغير بس وشوف الفرق بنفسك