LINQ و Collections

#اختار أقل collection contract يعبّر عن المطلوبChoose the collection contract you need

لما method محتاجة تقرا عناصر بس، إجبار المستدعي يبعت List بيضيّق الاستخدام من غير فايدة. اختار interface حسب العمليات المطلوبة، من غير ما توعد بـ immutability مش موجودة.

IEnumerable<T>
  +-- ICollection<T>       Count, Add, Remove, IsReadOnly
  |     +-- IList<T>      indexed get/set, Insert, RemoveAt
  |     +-- ISet<T>       set operations
  +-- IReadOnlyCollection<T>   Count
  |     +-- IReadOnlyList<T>   indexed get
  +-- IQueryable<T>       Expression, Provider, ElementType

IReadOnlyList<T> does not inherit IList<T>.

static decimal Total(IEnumerable<decimal> prices) => prices.Sum();

var mutable = new List<int> { 1, 2 };
IReadOnlyList<int> view = mutable;  // (1)
mutable.Add(3);
Console.WriteLine(view.Count);     // (2) 3

IEnumerable مش وعد إن المصدر lazy أو رخيص أو قابل للتكرار. ICollection ممكن يكون fixed-size أو read-only، وساعتها عمليات التعديل ترمي NotSupportedException. ماتعدّلش List أثناء foreach؛ استخدم RemoveAll أو iteration محسوبة.

#Array و List و LinkedList: تكلفة العملياتArray, List and LinkedList costs

اختيار collection حسب عبارة «الإضافة فيها أسرع» من غير تحديد المكان بيؤدي لقرار غلط. لازم تحسب تكلفة الوصول للمكان كمان.

var ids = new List<int>(capacity: 1000); // (1)
ids.Add(10);
ids.Add(20);
ids.RemoveAll(id => id < 15);           // (2)

var queue = new LinkedList<int>();
var node = queue.AddLast(20);
queue.AddBefore(node, 10);              // (3)

ابدأ بـ List للاستخدام العام. Queue و Stack أوضح من LinkedList لو المطلوب FIFO أو LIFO بس.

#Dictionary و HashSet: فهرس بدل البحث المتكررDictionary and HashSet: index repeated lookups

foreach (var line in lines)
{
    var product = products.First(p => p.Id == line.ProductId);
    Console.WriteLine(product.Name);
}

var byId = products.ToDictionary(p => p.Id);        // (1)
foreach (var line in lines)
{
    if (byId.TryGetValue(line.ProductId, out var p)) // (2)
        Console.WriteLine(p.Name);
}

var emails = new HashSet<string>(StringComparer.OrdinalIgnoreCase);
bool added = emails.Add("buyer@example.com");
bool duplicate = emails.Add("BUYER@example.com"); // false

Hash collisions ممكن تخلّي العملية O(n) في أسوأ حالة. List.Contains بحث O(n)، و SortedDictionary عملياته O(log n) ومرتّب بالـ key. Equal keys لازم نفس hash؛ ماتعدّلش fields داخلة في hash أثناء وجود key في collection، وماتعتمدش على ترتيب Dictionary كـ contract.

#IEnumerable و IQueryable والـ SQL الناتجIEnumerable, IQueryable and generated SQL

IQueryable مع EF Core زي طلب محدد للمخزن: «هات الأعمدة دي للطلبات الكبيرة». IEnumerable يعرّف iteration، و Enumerable operators اللي بعد الحد الفاصل بتشتغل بكود .NET على العناصر الراجعة.

var big = db.Orders
    .AsEnumerable()                         // (1)
    .Where(o => o.Total > 1000m)
    .Select(o => new { o.Id, o.Total })
    .ToList();

var query = db.Orders
    .Where(o => o.Total > 1000m)             // (2)
    .Select(o => new { o.Id, o.Total });
Console.WriteLine(query.ToQueryString());    // (3)
var big = await query.ToListAsync(ct);

-- Representative SQL Server output; aliases vary by provider/version.
-- Before: all mapped order columns, no Total predicate.
SELECT [o].[Id], [o].[CustomerId], [o].[Total], [o].[Status]
FROM [Orders] AS [o];

-- After:
SELECT [o].[Id], [o].[Total]
FROM [Orders] AS [o]
WHERE [o].[Total] > 1000.0;

مش كل IQueryable مصدره SQL، ومش كل expression قابل للترجمة. EF Core الحديث بيرفض غالباً تعبير غير قابل للترجمة في Where؛ top-level projection ممكن يحتوي client evaluation. خلي query composition داخل حدود عمر DbContext، وراجع SQL وخطة التنفيذ.

#Deferred execution وفخ إعادة enumerationDeferred execution and repeated enumeration

الـ query زي وصفة؛ كتابتها مش معناها إن الأكل اتعمل. Where و Select مؤجلين وبيشتغلوا تدريجياً؛ OrderBy و GroupBy في LINQ-to-Objects مؤجلين لكن محتاجين buffering قبل أول نتيجة.

var ids = new List<int> { 1, 2, 3 };
var query = ids.Where(id => id > 1);        // (1)
ids.Add(4);
Console.WriteLine(query.Count());           // (2) 3
var snapshot = query.ToArray();             // (3)
ids.Add(5);
Console.WriteLine(snapshot.Length);         // 3

var paid = db.Orders.Where(o => o.Status == "Paid");
bool exists = await paid.AnyAsync(ct);      // (4) query one
decimal total = await paid.SumAsync(o => o.Total, ct); // query two

لو محتاج العناصر أكتر من مرة وحجمها مناسب، materialize مرة. لو محتاج total بس، شيل Any واعمل aggregate في database بدل تحميل الجدول. IEnumerable مش بيضمن إن مصدر file أو network قابل لإعادة القراءة. Immediate operators تشمل ToList، و ToDictionary، و First، و Any، و Sum.

#Select و SelectMany و GroupByProjection, flattening and grouping

اختار شكل النتيجة الأول: عنصر لكل order، ولا كل lines في sequence واحدة، ولا مجموع لكل customer؟ دي تلات عمليات مختلفة.

var totals = orders.Select(o => o.Total);                 // (1)
var lines = orders.SelectMany(o => o.Lines);             // (2)
var detail = orders.SelectMany(o => o.Lines,
    (o, line) => new { OrderId = o.Id, line.ProductId });

var revenue = orders.GroupBy(o => o.CustomerId)           // (3)
    .Select(g => new
    {
        CustomerId = g.Key,
        Count = g.Count(),
        Total = g.Sum(o => o.Total)
    });

في memory، GroupBy بيحتفظ بالعناصر في مجموعات. لو محتاج counts بس شوف CountBy. في EF Core، grouping مع scalar aggregates غالباً يترجم لـ GROUP BY؛ إرجاع groups كاملة مش نفس شكل SQL. ماتضمنش ترجمة أي SelectMany: شكل التعبير والـ provider مهمين.

#Join و LeftJoin في .NET 10Join and .NET 10 LeftJoin

Inner join بيحذف اللي ملوش match. تقرير العملاء لازم أحياناً يعرض العميل حتى لو معندوش orders؛ هنا محتاج left join، والـ right side ممكن يبقى null.

var matched = customers.Join(orders,                    // (1)
    c => c.Id, o => o.CustomerId,
    (c, o) => new { c.Name, OrderId = o.Id });

var all = customers.LeftJoin(orders,                    // (2) .NET 10
    c => c.Id, o => o.CustomerId,
    (c, o) => new { c.Name, OrderId = o == null ? (int?)null : o.Id });

// Before .NET 10:
var old = from c in customers
          join o in orders on c.Id equals o.CustomerId into matches
          from o in matches.DefaultIfEmpty()           // (3)
          select new { c.Name, OrderId = o == null ? (int?)null : o.Id };

مع IQueryable استخدم EF Core 10 و provider متوافق، وراجع SQL. Join مش بيضمن إزالة التكرار، و WHERE على أعمدة الجانب اليمين بعد left join ممكن يستبعد missing rows لو الشرط مش بيسمح بـ null.

#First و Single و Any و AllElement selection and quantifiers

اختيار operator بيعبّر عن contract: «هات أول واحد» غير «لازم واحد بالظبط». ما تخبيش duplicate bug باستعمال First لمجرد إنه أسهل.

bool hasPaid = orders.Any(o => o.Status == "Paid");       // (1)
bool allPaid = orders.All(o => o.Status == "Paid");       // (2)
bool nonEmptyAndPaid = orders.Count > 0 && allPaid;       // List<Order>
int absent = Array.Empty<int>().FirstOrDefault();         // (3) 0

Count property في List بتتكلف O(1)، و Count() ممكن يستفيد من collection count؛ مش كل Count بيعمل scan. Single مش بديل لـ unique constraint في database، و First محتاج ترتيب صريح لو معنى «الأول» مهم.

#الترتيب والـ pagination: offset و keysetOrdering and pagination: offset versus keyset

صفحات الطلبات محتاجة ترتيب ثابت وفريد، وإلا عناصر تتكرر أو تختفي حتى من غير bug في الواجهة. OrderBy يبدأ ترتيب أساسي جديد؛ ThenBy يضيف tie-breaker.

int pageSize = 20;
var offsetPage = await db.Orders
    .OrderBy(o => o.CreatedAt).ThenBy(o => o.Id)          // (1)
    .Skip((pageNumber - 1) * pageSize).Take(pageSize)
    .Select(o => new { o.Id, o.CreatedAt, o.Total })
    .ToListAsync(ct);

var nextPage = await db.Orders
    .Where(o => o.CreatedAt > lastTime ||                 // (2)
        (o.CreatedAt == lastTime && o.Id > lastId))
    .OrderBy(o => o.CreatedAt).ThenBy(o => o.Id)
    .Take(pageSize).ToListAsync(ct);

Offset يسمح بالقفز لصفحة برقم، لكن deep offsets بتعمل شغل أكتر وصفحاتها بتتزحزح مع inserts و deletes. Keyset مناسب Next و Previous ومش بيعدّي على كل الصفوف السابقة، لكنه مش بيوفّر قفز عشوائي بسهولة. لو sort key اتغير أثناء التصفح، لسه ممكن يحصل تغيير في النتائج؛ cursor مش snapshot transaction.

#Chunk و DistinctBy و CountBy و AggregateByBatching, deduplication and per-key aggregates

لو محتاج تبعت batches أو counts بس، مش لازم تبني groups كاملة أو تكتب loops متداخلة. الأمثلة دي LINQ-to-Objects؛ وجود operator في Enumerable مش ضمان إن EF يترجمه.

foreach (var batch in orders.Chunk(100))                  // (1) .NET 6
    Console.WriteLine(batch.Length);

var unique = products.DistinctBy(p => p.Sku,
    StringComparer.OrdinalIgnoreCase);                  // (2) .NET 6

var counts = orders.CountBy(o => o.CustomerId);          // (3) .NET 9
var totals = orders.AggregateBy(o => o.CustomerId,
    seed: 0m, func: (sum, order) => sum + order.Total);   // (4) .NET 9

البديل القديم CountBy هو GroupBy ثم Count؛ و AggregateBy هو GroupBy ثم aggregate. Chunk على query بعد AsEnumerable مش database pagination، ولو بتعمل materialize لكل الجدول الأول فقدت فايدة streaming.

#Frozen و immutable collections والمشاركة بين threadsFrozen, immutable and concurrent collections

لو catalog للقراءة الكتير والتحديث النادر، كل reader مش محتاج lock حوالين dictionary بيتغير. ابنِ snapshot مناسب وحدد إزاي هتنشر النسخة الجديدة بأمان.

using System.Collections.Frozen;
using System.Collections.Immutable;

var prices = new Dictionary<int, decimal> { [10] = 120m };
FrozenDictionary<int, decimal> frozen = prices.ToFrozenDictionary(); // (1)

var original = ImmutableDictionary<int, decimal>.Empty.Add(10, 120m);
var changed = original.SetItem(10, 125m);                            // (2)
Console.WriteLine(original[10]); // 120
Console.WriteLine(changed[10]);  // 125

Frozen مناسب build-once/read-many؛ immutable مناسب إصدارات متعددة مع updates. الاتنين مش بيخلّوا mutable values جواهم immutable. لو عايز shared mutable collection، شوف ConcurrentDictionary و Channels في موضوع 04: Async و multithreading. Immutable snapshot كمان محتاج atomic publication لو أكتر من writer بيحدّثه.