Back to "डेटा अभिगम में .NET: ओआरएमों और मानचित्रण रणनीतियों का तुलना करना | ( | भाग |1 | \ - | अस्तित्व फ्रेमवर्क कोर"

This is a viewer only at the moment see the article on how this works.

To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk

# डेटा अभिगम में .NET: ओआरएमों और मानचित्रण रणनीतियों का तुलना करना | ( | भाग |1 | \ - | अस्तित्व फ्रेमवर्क कोर

<datetime class="hidden">2025-12-03T14:00</datetime>

निर्माण के दौरान | . | नेट अनुप्रयोगों |, | आप द्वारा किए जाने वाले सबसे महत्वपूर्ण वास्तुकला निर्णयों में से एक है डेटा अभिगम और ऑब्जेक्ट मैपिंग को कैसे नियंत्रित किया जाए।

इस व्यापक दो खंडों में--part guide, , हम,', हमारे उदाहरणों में Npgsql के साथ PostgreSQL का उपयोग करते हुए, सबसे लोकप्रिय डेटा अभिगम पैटर्नों को खोजेंगे।

**भाग 1** इकाई फ्रेमवर्क कोर पर ध्यान केंद्रित करता है
**भाग 2** Dapper, raw ADO.NETM SK2 object mapping libraries

## संबंधित लेख

यदि आप व्यावहारिक एफ कोर क्रियान्वयन में रुचि रखते हैं

- [ब्लॉग पोस्टों के लिए अस्तित्व फ्रेमवर्क जोड़ना](/blog/addingentityframeworkforblogpostspt1) - आरंभिक से एफ कोर सेटअप करना
- [ईएफ प्रवास सही रास्ते में](/blog/efmigrationstherightway) - उत्पादन में सही तरीके से उत्प्रवासों को संभालना
- [पूर्ण पाठ खोज रहा है (Pt](/blog/textsearchingpt1) - PostgreSQL पूर्ण का कार्यान्वयन EF कोर के साथ पाठ खोज
- [आधुनिक सीक्यूआरएस और घटना खोज](/blog/moderncqrsandeventsourcing) - ईएफ कोर के साथ उन्नत वास्तुकला नमूने

## विषयसूची

## डेटा अभिगम दृष्टिकोणों की स्पेक्ट्रम

डेटा अभिगम परिदृश्य को एक स्पेक्ट्रम के रूप में दृश्यीकृत किया जा सकता है

```
Full Abstraction                                      Full Control
     ↓                                                      ↓
[EF Core] → [EF Core Raw SQL] → [Dapper] → [Npgsql ADO.NET]
```

जैसे-जैसे आप बाएं से दाएँ बढ़ते हैं, आप निष्पादन और नियंत्रण प्राप्त करते हैं लेकिन सुविधा और स्वचालित सुविधाओं को खो देते हैं

### डेटा एक्सेस फ्लो तुलना

यहाँ एक दृश्यात्मक तुलना है कि कैसे प्रत्येक दृष्टिकोण एक विशिष्ट क्वेरी को संभालता है

style A1 stroke:#2563eb,stroke-width:2px
    style B1 stroke:#2563eb,stroke-width:2px
    style C1 stroke:#2563eb,stroke-width:2px
    style D1 stroke:#2563eb,stroke-width:2px
    style E1 stroke:#2563eb,stroke-width:2px
    style F1 stroke:#2563eb,stroke-width:2px
    style G1 stroke:#2563eb,stroke-width:2px

style A2 stroke:#059669,stroke-width:2px
    style B2 stroke:#059669,stroke-width:2px
    style C2 stroke:#059669,stroke-width:2px
    style D2 stroke:#059669,stroke-width:2px
    style E2 stroke:#059669,stroke-width:2px
    style F2 stroke:#059669,stroke-width:2px

style A3 stroke:#dc2626,stroke-width:2px
    style B3 stroke:#dc2626,stroke-width:2px
    style C3 stroke:#dc2626,stroke-width:2px
    style D3 stroke:#dc2626,stroke-width:2px
    style E3 stroke:#dc2626,stroke-width:2px
    style F3 stroke:#dc2626,stroke-width:2px
```

### निष्पादन विपरीत विकासकर्ता उत्पादकता व्यापार

```mermaid
graph LR
 A[High Productivity Low Performance] --> B[EF Core Full Tracking]
 B --> C[EF Core No Tracking]
 C --> D[EF Core Raw SQL]
 D --> E[Dapper]
 E --> F[Raw Npgsql]
 F --> G[Low Productivity High Performance]

style A stroke:#2563eb,stroke-width:2px
    style B stroke:#2563eb,stroke-width:2px
    style C stroke:#3b82f6,stroke-width:2px
    style D stroke:#059669,stroke-width:2px
    style E stroke:#059669,stroke-width:2px
    style F stroke:#dc2626,stroke-width:2px
    style G stroke:#dc2626,stroke-width:2px
```

## अस्तित्व फ्रेमवर्क कोर

[इकाई फ्रेमवर्क कोर](https://learn.microsoft.com/en-us/ef/core/) है माइक्रोसॉफ्ट'स् फ्लैगशिप ORM, आपके डेटाबेस पर एक पूर्ण अमूर्ति प्रदान करता है [Npgsql.EntityFrameworkCore.PostgreSQL](https://www.npgsql.org/efcore/) प्रदाता.

अपने परियोजना में ईएफ कोर को स्थापित करने के लिए व्यावहारिक मार्गदर्शन हेतु [ब्लॉग पोस्ट के लिए अस्तित्व फ्रेमवर्क जोड़ना](/blog/addingentityframeworkforblogpostspt1).

### मुख्य विशेषताएँ

- **ट्रैकिंग बदलें**: स्वचालित रूप से इकाई परिवर्तनों को ट्रैक करता है और उपयुक्त SQL उत्पन्न करता है
- **प्रवास**कोड [ईएफ प्रवास सही रास्ते में](/blog/efmigrationstherightway))
- **LINQ प्रदाता**: प्रकार
- **लचीला/अत्यावश्यक लोड**: संबंधित इकाइयों के लिए लचीला लोडिंग रणनीति
- **उन्नत PostgreSQL विशेषताएँ**पूर्ण[मेरा लेख देखें](/blog/textsearchingpt1)), JSON स्तंभों
- **अवरोधक और घटनाएँ**: Cross--cutting चिंताओं के लिए विस्तार बिंदु

### उदाहरण: EF कोर के साथ बुनियादी CRUD

```csharp
public class BlogDbContext : DbContext
{
 public DbSet<BlogPost> BlogPosts { get; set; }
 public DbSet<Comment> Comments { get; set; }

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseNpgsql("Host=localhost;Database=blog;Username=postgres;Password=secret");
    }

protected override void OnModelCreating(ModelBuilder modelBuilder)
 {
 // PostgreSQL-specific: Full-text search
 modelBuilder.Entity<BlogPost>()
 .HasGeneratedTsVectorColumn(
 p => p.SearchVector,
 "english",
 p => new { p.Title, p.Content })
 .HasIndex(p => p.SearchVector)
 .HasMethod("GIN");

// PostgreSQL array type
 modelBuilder.Entity<BlogPost>()
 .Property(p => p.Tags)
 .HasPostgresArrayConversion(
 tag => tag.ToLowerInvariant(),
 tag => tag);
 }
}

public class BlogPost
{
 public int Id { get; set; }
 public string Title { get; set; }
 public string Content { get; set; }
 public string[] Tags { get; set; }
 public NpgsqlTsVector SearchVector { get; set; }
 public List<Comment> Comments { get; set; }
 public DateTime PublishedDate { get; set; }
}

// Usage
public class BlogService
{
    private readonly BlogDbContext _context;

public async Task<List<BlogPost>> GetRecentPostsAsync(int count)
 {
 return await _context.BlogPosts
 .Include(p => p.Comments)
 .OrderByDescending(p => p.PublishedDate)
 .Take(count)
 .ToListAsync();
 }

public async Task<List<BlogPost>> SearchPostsAsync(string searchTerm)
 {
 return await _context.BlogPosts
 .Where(p => p.SearchVector.Matches(EF.Functions.ToTsQuery("english", searchTerm)))
 .ToListAsync();
 }

public async Task AddPostAsync(BlogPost post)
    {
        _context.BlogPosts.Add(post);
        await _context.SaveChangesAsync();
    }
}
```

### रॉ SQL के साथ ईएफ कोर

एफ कोर भी raw SQL क्वेरी को समर्थन करता है जब आपको अधिक नियंत्रण की आवश्यकता होती है

```csharp
public async Task<List<BlogPost>> GetPostsByComplexCriteriaAsync()
{
 var searchTerm = "postgresql";

return await _context.BlogPosts
        .FromSqlInterpolated($@"
            SELECT * FROM ""BlogPosts""
            WHERE ""SearchVector"" @@ to_tsquery('english', {searchTerm})
            AND array_length(""Tags"", 1) > 3
            ORDER BY ts_rank(""SearchVector"", to_tsquery('english', {searchTerm})) DESC
        ")
        .ToListAsync();
}

// Or with DbDataReader for maximum control
public async Task<List<PostStatistics>> GetPostStatisticsAsync()
{
 using var command = _context.Database.GetDbConnection().CreateCommand();
 command.CommandText = @"
 SELECT
 DATE_TRUNC('month', ""PublishedDate"") as Month,
 COUNT(*) as PostCount,
 AVG(ARRAY_LENGTH(""Tags"", 1)) as AvgTags
 FROM ""BlogPosts""
 GROUP BY DATE_TRUNC('month', ""PublishedDate"")
 ORDER BY Month DESC";

await _context.Database.OpenConnectionAsync();

var results = new List<PostStatistics>();
 using var reader = await command.ExecuteReaderAsync();

while (await reader.ReadAsync())
    {
        results.Add(new PostStatistics
        {
            Month = reader.GetDateTime(0),
            PostCount = reader.GetInt32(1),
            AverageTags = reader.GetDouble(2)
        });
    }

return results;
}
```

### ईएफ कोर को कब प्रयोग करना है

**EF कोर का उपयोग करें जब**

- विकासशील स्कीमा आवश्यकताओं के साथ एक नया अनुप्रयोग बनाना
- आपको मजबूत टाइपिंग और कम्पाइल की जरूरत है
- माइग्रेसन और स्कीमा संस्करणिंग महत्वपूर्ण हैं [मेरी प्रवासी मार्गदर्शक](/blog/efmigrationstherightway))
- आपकी टीम SQL से अधिक ऑब्जेक्टों के साथ काम करना पसंद करती है
- आप संबंधों के साथ जटिल डोमेन मॉडल का उपयोग कर रहे हैं
- विकास गति कच्चे निष्पादन से अधिक महत्वपूर्ण है
- आप को cross-डेटाबेस पोर्टेबलता की आवश्यकता है।

**EF कोर से बचें जब**

- अधिकतम निष्पादन महत्वपूर्ण है
- आपके पास जटिल,hand-tuned SQL क्वेरी हैं
- आपकी क्वेरी ग्राफ्स ऑब्जेक्ट के लिए अच्छी तरह से नक्शे नहीं map
- आपको प्रत्येक एसक्यूएल कथन पर fine-रक्षित नियंत्रण की जरूरत है
- स्मृति उपयोग एक महत्वपूर्ण अवरोध है
- आप ''' legacy schemas के साथ काम कर रहे हैं जो don''' conventions में नक्शा नहीं

## ईएफ कोर एसक्यूएल जेनरेशन

ईएफ कोर का प्रभावी उपयोग करने के सबसे महत्वपूर्ण पहलुओं में से एक यह समझना है कि क्या एसक्यूएल यह उत्पन्न करता है।

### Generated SQL को देख रहा है

```csharp
// Enable sensitive data logging and detailed errors (development only!)
optionsBuilder
    .UseNpgsql(connectionString)
    .EnableSensitiveDataLogging()
    .EnableDetailedErrors()
    .LogTo(Console.WriteLine, LogLevel.Information);

// Or use logging to see SQL
public class BlogService
{
 private readonly BlogDbContext _context;
 private readonly ILogger<BlogService> _logger;

public async Task<List<BlogPost>> GetPostsAsync()
 {
 var query = _context.BlogPosts
 .Where(p => p.PublishedDate > DateTime.UtcNow.AddDays(-30))
 .OrderByDescending(p => p.PublishedDate);

// View the SQL before execution
        var sql = query.ToQueryString();
        _logger.LogInformation("Executing query: {Sql}", sql);

return await query.ToListAsync();
    }
}
```

### उदाहरण: साधारण क्वेरी

**C# LINQ**

```csharp
var recentPosts = await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .OrderByDescending(p => p.PublishedDate)
    .Take(10)
    .ToListAsync();
```

**Generated SQL ([ईएफ कोर 8+](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-8.0/whatsnew)):**

```sql
SELECT b."Id", b."Title", b."Content", b."CategoryId", b."PublishedDate"
FROM "BlogPosts" AS b
WHERE b."CategoryId" = @__categoryId_0
ORDER BY b."PublishedDate" DESC
LIMIT @__p_1
```

ध्यान दें कि कैसे एफ कोर 8+ उचित पैरामीटरीकरण के साथ स्वच्छ, कुशल SQL उत्पन्न करता है [ईएफ कोर 10](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-10.0/whatsnew) इस प्रवृत्ति को और अधिक सुधार के साथ जारी रखता है

### उदाहरण: शामिल करने के साथ जोड़ें | ( | EF कोर से पहले

**कोड**

```csharp
var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .ToListAsync();
```

**पुराना एसक्यूएल (EF कोर**

```sql
SELECT b."Id", b."Title", c."Id", c."Name", cm."Id", cm."Content"
FROM "BlogPosts" AS b
LEFT JOIN "Categories" AS c ON b."CategoryId" = c."Id"
LEFT JOIN "Comments" AS cm ON b."Id" = cm."BlogPostId"
ORDER BY b."Id", c."Id"
```

यह एक बनाता है **कार्टेशियन उत्पाद** यदि एक पोस्ट में 10 टिप्पणी है तो यह पंक्ति दोहराया जाता है

### उदाहरण: विभाजित क्वेरी

**Split Query के साथ कोड**

```csharp
var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .AsSplitQuery()  // ← This is the key!
    .ToListAsync();
```

**Generated SQL (Multiple Queries):**

```sql
-- Query 1: Get posts and categories
SELECT b."Id", b."Title", b."Content", c."Id", c."Name"
FROM "BlogPosts" AS b
LEFT JOIN "Categories" AS c ON b."CategoryId" = c."Id"

-- Query 2: Get comments for those posts
SELECT cm."Id", cm."Content", cm."BlogPostId"
FROM "Comments" AS cm
INNER JOIN (
    SELECT b."Id"
    FROM "BlogPosts" AS b
) AS t ON cm."BlogPostId" = t."Id"
ORDER BY t."Id"
```

यह कार्टेशियन उत्पाद को समाप्त करता है और प्रायः **अधिक तेजी से** संग्रह के लिए

### उदाहरण: फिल्टर किए गए में शामिल है (EF कोर 5+)

**कोड**

```csharp
var posts = await _context.BlogPosts
    .Include(p => p.Comments.Where(c => c.IsApproved))
    .ToListAsync();
```

**बनाया गया SQL:**

```sql
SELECT b."Id", b."Title", b."Content", t."Id", t."Content", t."IsApproved"
FROM "BlogPosts" AS b
LEFT JOIN (
    SELECT c."Id", c."Content", c."IsApproved", c."BlogPostId"
    FROM "Comments" AS c
    WHERE c."IsApproved" = TRUE
) AS t ON b."Id" = t."BlogPostId"
ORDER BY b."Id"
```

### उदाहरण: JSON स्तम्भ क्वेरी

**कोड**

```csharp
public class BlogPost
{
    public int Id { get; set; }
    public string Title { get; set; }
    public PostMetadata Metadata { get; set; }  // Stored as JSONB
}

public class PostMetadata
{
 public bool IsFeatured { get; set; }
 public int ViewCount { get; set; }
 public List<string> RelatedTags { get; set; }
}

// Query JSON properties
var featuredPosts = await _context.BlogPosts
    .Where(p => p.Metadata.IsFeatured)
    .ToListAsync();
```

**बनाया गया SQL:**

```sql
SELECT b."Id", b."Title", b."Metadata"
FROM "BlogPosts" AS b
WHERE b."Metadata" ->> 'IsFeatured' = 'true'
```

EF कोर 7+ PostgreSQL JSON ऑपरेटरों के लिए JSON गुण अभिगम का अनुवाद कर सकता है

### उदाहरण: बल्क अद्यतन (EF कोर | 7+ | निष्पादित अद्यतन

**पुराना तरीका (अक्षम**

```csharp
var posts = await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ToListAsync();

foreach (var post in posts)
{
    post.IsArchived = true;
}

await _context.SaveChangesAsync();  // Generates N UPDATE statements!
```

**नया रास्ता**

```csharp
await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(p => p.IsArchived, true));
```

**Generated SQL (Single Query!):**

```sql
UPDATE "BlogPosts" AS b
SET "IsArchived" = TRUE
WHERE b."CategoryId" = 5
```

यह एक है **विशाल** सुधार - एक एसक्यूएल कथन N के बजाय

### उदाहरण: बल्क मिटाएँ (EF कोर 7+)

**ओल्ड वे**

```csharp
var oldPosts = await _context.BlogPosts
 .Where(p => p.PublishedDate < DateTime.UtcNow.AddYears(-5))
 .ToListAsync();

_context.BlogPosts.RemoveRange(oldPosts);
await _context.SaveChangesAsync();  // N DELETE statements
```

**नया रास्ता**

```csharp
await _context.BlogPosts
 .Where(p => p.PublishedDate < DateTime.UtcNow.AddYears(-5))
 .ExecuteDeleteAsync();
```

**बनाया गया SQL:**

```sql
DELETE FROM "BlogPosts" AS b
WHERE b."PublishedDate" < @__p_0
```

### उदाहरण: जटिल समूह

**कोड**

```csharp
var categoryStats = await _context.Categories
    .Select(c => new CategoryStats
    {
        CategoryName = c.Name,
        PostCount = c.BlogPosts.Count(),
        LatestPostDate = c.BlogPosts.Max(p => p.PublishedDate),
        AverageComments = c.BlogPosts.Average(p => p.Comments.Count)
    })
    .ToListAsync();
```

**Generated SQL (EF Core 8+/10):**

```sql
SELECT c."Name" AS "CategoryName",
       COUNT(*)::int AS "PostCount",
       MAX(b."PublishedDate") AS "LatestPostDate",
       COALESCE(AVG((
           SELECT COUNT(*)::int
           FROM "Comments" AS c0
           WHERE b."Id" = c0."BlogPostId"
       ))::double precision, 0.0) AS "AverageComments"
FROM "Categories" AS c
LEFT JOIN "BlogPosts" AS b ON c."Id" = b."CategoryId"
GROUP BY c."Id", c."Name"
```

### पोस्टग्रेएसक्यूएल पूर्ण

अधिक गहराई के लिए पूरा ढूंढें [ईएफ कोर के साथ पूरा पाठ खोज लागू करना](/blog/textsearchingpt1).

**कोड**

```csharp
var searchResults = await _context.BlogPosts
    .Where(p => p.SearchVector.Matches(EF.Functions.ToTsQuery("english", "postgresql & performance")))
    .OrderByDescending(p => p.SearchVector.Rank(EF.Functions.ToTsQuery("english", "postgresql & performance")))
    .Take(20)
    .ToListAsync();
```

**बनाया गया SQL:**

```sql
SELECT b."Id", b."Title", b."Content", b."SearchVector"
FROM "BlogPosts" AS b
WHERE b."SearchVector" @@ to_tsquery('english', @__searchTerm_0)
ORDER BY ts_rank(b."SearchVector", to_tsquery('english', @__searchTerm_0)) DESC
LIMIT 20
```

## Critical EF Core Warnings and Pitfalls

### 1. ट्रैकिंग मेमोरी लीक बदलें

**समस्या**

```csharp
// ❌ DANGER: This can cause memory leaks!
public class PostCache
{
 private readonly BlogDbContext _context;
 private List<BlogPost> _cachedPosts;

public PostCache(BlogDbContext context)
    {
        _context = context;
    }

public async Task LoadCacheAsync()
    {
        // These entities are now tracked by the context
        _cachedPosts = await _context.BlogPosts.ToListAsync();

// The DbContext holds references to these entities FOREVER
        // They can never be garbage collected while the context lives!
    }
}
```

**क्या यह एक समस्या है**

- ट्रैक किए गए अस्तित्वों का जीवनकाल के लिए स्मृति में रहते हैं `DbContext`
- परिवर्तन ट्रैकर संदर्भ रखता है
- लम्बे -जीवन संदर्भ (e.gM SK3 एकलटन SSK4 = स्मृति लीक
- ASP में .NET Core, संदर्भ पूर्वनिर्धारित रूप से स्कोप किया जाता है
- लेकिन यदि आप कैश ट्रैक किए गए इकाइयों को खींचते हैं, आप' समस्या में है

**समाधान**

```csharp
public async Task LoadCacheAsync()
{
    // ✅ Use AsNoTracking() for read-only queries
    _cachedPosts = await _context.BlogPosts
        .AsNoTracking()
        .ToListAsync();

// Or detach entities after loading
    var posts = await _context.BlogPosts.ToListAsync();
    foreach (var post in posts)
    {
        _context.Entry(post).State = EntityState.Detached;
    }
    _cachedPosts = posts;
}
```

### 2. प्रॉक्सी जनन और लचीले लोडिंग खतरा

> **🚨 क्रिटिकल चेतावनी**
> 
> लचीला लोडिंग प्रॉक्सी **गारंटीकृत स्मृति लीक**
> 
> यदि आप क्यास DbContext इंस्टैंस या क्यास एंटिटीज सक्रिय proxies के साथ लोड किया है **WILL** लीक मेमोरी. प्रॉक्सी तंत्र डीबी संदर्भ के संदर्भों को बनाए रखता है।
> 
> **अंगूठी नियम**: हमेशा संग्रहों को स्पष्ट रूप से साथ शामिल करें `.Include()`. केवल प्रॉक्सी का उपयोग करें यदि आप सौदाओं को पूरी तरह समझते हैं और कभी भी नहीं

**समस्या 1: The N+1 Query Nightmare**

```csharp
// ❌ Enable lazy loading
optionsBuilder
    .UseNpgsql(connectionString)
    .UseLazyLoadingProxies();  // Convenient but dangerous!

public class BlogPost
{
 public int Id { get; set; }
 public string Title { get; set; }
 public virtual Category Category { get; set; } // Virtual = proxy
 public virtual List<Comment> Comments { get; set; }
}

// Somewhere in your code
var posts = await _context.BlogPosts.ToListAsync();

foreach (var post in posts)
{
    Console.WriteLine(post.Category.Name);  // N+1 query here!
    Console.WriteLine(post.Comments.Count);  // Another N+1 query!
}
```

**क्या होता है**

1. पहला क्वेरी सभी पोस्ट लोड करता है
2. के लिए **प्रत्येक पद**अभिगम `Category` एक डाटाबेस क्वेरी ट्रिगर करता है
3. के लिए **प्रत्येक पद**अभिगम `Comments` एक और क्वेरी ट्रिगर करता है
4. यदि आपके पास 100 पोस्ट है **201 प्रश्न**!

**समस्या 2: प्रॉक्सी + कैचिंग = मेमोरी लीक**

```csharp
// ❌ CATASTROPHIC: Lazy loading proxies + caching
public class BlogPostCache
{
 private static List<BlogPost> _cachedPosts;
 private readonly BlogDbContext _context;

public BlogPostCache()
 {
 var optionsBuilder = new DbContextOptionsBuilder<BlogDbContext>();
 optionsBuilder
 .UseNpgsql(connectionString)
 .UseLazyLoadingProxies(); // ⚠️ DANGER!

_context = new BlogDbContext(optionsBuilder.Options);
    }

public async Task<List<BlogPost>> GetCachedPostsAsync()
 {
 if (_cachedPosts == null)
 {
 // ❌ These proxy entities hold references to _context
 _cachedPosts = await _context.BlogPosts.ToListAsync();
 }
 return _cachedPosts;
 }
}
```

**यह विनाशकारी क्यों है**

- प्रॉक्सी इकाइयां अपने `DbContext`
-  `DbContext` सभी ट्रैक किए गए इकाइयों के लिए संदर्भ रखता है
- आपका कैश अब संपूर्ण वस्तु ग्राफ को कचरा डाक एकत्रित होने से रोकता है
- हर बार जब आप एक नेविगेशन गुण अभिगम करता है, यह क्वेरी ट्रिगर कर सकता है के उपयोग से **पुराना, कैश संदर्भ**
- जब आप अधिक डेटा लोड करते हैं, स्मृति बिना सीमाओं के बढ़ती है
- आप अंततः मेमोरी या बाहरी कनेक्शन पूलों से बाहर चला जाएगा

**समाधान: स्पष्ट होना**

```csharp
// ✅ NEVER use lazy loading proxies - always be explicit
optionsBuilder
    .UseNpgsql(connectionString);
    // NO .UseLazyLoadingProxies()!

public class BlogPost
{
 public int Id { get; set; }
 public string Title { get; set; }
 public Category Category { get; set; } // NOT virtual
 public List<Comment> Comments { get; set; } // NOT virtual
}

// ✅ Explicit eager loading - you control what's loaded
var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .ToListAsync();

// ✅ Or use split queries for better performance
var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .AsSplitQuery()
    .ToListAsync();

// ✅ Or use projection to DTOs (best for caching)
var posts = await _context.BlogPosts
    .Select(p => new PostDto
    {
        Title = p.Title,
        CategoryName = p.Category.Name,
        CommentCount = p.Comments.Count
    })
    .ToListAsync();

// ✅ If you MUST cache, use AsNoTracking and no proxies
public class SafeBlogPostCache
{
 private static List<BlogPost> _cachedPosts;
 private readonly IDbContextFactory<BlogDbContext> _contextFactory;

public async Task<List<BlogPost>> GetCachedPostsAsync()
 {
 if (_cachedPosts == null)
 {
 using var context = await _contextFactory.CreateDbContextAsync();

_cachedPosts = await context.BlogPosts
                .Include(p => p.Category)
                .Include(p => p.Comments)
                .AsNoTracking()  // Critical for caching!
                .ToListAsync();
        }
        return _cachedPosts;
    }
}
```

**जब प्रॉक्सी स्वीकार्य हो सकता है (ट्रेडऑफ्स को समझें**

लचीले लोडिंग प्रॉक्सी तभी स्वीकार्य हो सकते हैं जब

1. ✅ आपको **छोटा-जीवन** स्कोपित संदर्भ प्रति HTTP अनुरोध
2. ✅You **कभी नहीं** कैश इकाइयों
3. @info: whatsthis
4. ✅ आप' prototyping कर रहे हैं और बाद में अनुकूलन करेंगे
5. ✅ आपकी टीम पूरी तरह से implications समझता है

लेकिन फिर भी `Include()` लगभग हमेशा बेहतर विकल्प है क्योंकि

- यह डाटा लोड करता है **स्पष्ट और स्पष्ट**
- एमएसके0 **अनुकूलित करने में आसान** आप देख सकते हैं कि क्या लोड किया जा रहा है
- यह **अनियमित N+1 प्रश्नों को रोकता है**
- यह कैशिंग और दीर्घ---जीवन संदर्भों के साथ सही काम करता है
- यह' है **सिफारिशित दृष्टिकोण** एफ कोर टीम द्वारा

### 3. डीबी संदर्भ जीवनकाल मुद्दे

उत्पादन में डीबी कंटेक्स्ट जीवनकाल के प्रबंधन पर अधिक जानकारी के लिए [ईएफ प्रवास सही रास्ते में](/blog/efmigrationstherightway).

**समस्या**

```csharp
// ❌ NEVER do this - singleton DbContext
public void ConfigureServices(IServiceCollection services)
{
 services.AddSingleton<BlogDbContext>(); // WRONG!
}

// ❌ Also wrong - storing context in static field
public static class DataAccess
{
    private static BlogDbContext _context = new BlogDbContext();

public static async Task<BlogPost> GetPostAsync(int id)
 {
 return await _context.BlogPosts.FindAsync(id);
 }
}
```

**क्या यह गलत है**

- `DbContext` है **थ्रेड नहीं है**
- समवर्ती अनुरोधों से डेटा खराब हो जाएगा
- परिवर्तन ट्रैकर अपरिभाषित रूप से बढ़ता है
- कनेक्शन पूल समाप्ति
- कैश से डाटा रोकें

**समाधान**

```csharp
// ✅ Use scoped lifetime (default in ASP.NET Core)
public void ConfigureServices(IServiceCollection services)
{
 services.AddDbContext<BlogDbContext>(options =>
 options.UseNpgsql(connectionString));
}

// ✅ Or use DbContext factory for background services
public void ConfigureServices(IServiceCollection services)
{
 services.AddDbContextFactory<BlogDbContext>(options =>
 options.UseNpgsql(connectionString));
}

public class BlogBackgroundService
{
 private readonly IDbContextFactory<BlogDbContext> _contextFactory;

public async Task ProcessPostsAsync()
    {
        // Create a new context for this operation
        using var context = await _contextFactory.CreateDbContextAsync();

var posts = await context.BlogPosts.ToListAsync();
        // Process posts...
    }
}
```

### 4. अनपेक्षित नेविगेशन गुणों में शामिल है

**समस्या**

```csharp
public class BlogPost
{
 public int Id { get; set; }
 public string Title { get; set; }
 public List<Comment> Comments { get; set; }
}

// You query one post...
var post = await _context.BlogPosts.FirstAsync();

// Add a new comment
var newComment = new Comment { Content = "Great post!" };
post.Comments.Add(newComment);

await _context.SaveChangesAsync();

// ❌ EF Core saves the comment, BUT...
// If Comments wasn't loaded, you just lost all existing comments!
// The collection is empty, so EF thinks there are no other comments
```

**समाधान**

```csharp
// ✅ Always load navigation properties before modifying
var post = await _context.BlogPosts
    .Include(p => p.Comments)
    .FirstAsync(p => p.Id == postId);

post.Comments.Add(newComment);
await _context.SaveChangesAsync();

// Or add directly to the DbSet
_context.Comments.Add(new Comment
{
    BlogPostId = postId,
    Content = "Great post!"
});
await _context.SaveChangesAsync();
```

### 5. समन्वयन विपरीत समन्वयन मिक्सिंग

**समस्या**

```csharp
// ❌ Mixing sync and async - deadlock risk!
public async Task<BlogPost> GetPostAsync(int id)
{
 var post = _context.BlogPosts
 .Where(p => p.Id == id)
 .FirstOrDefault(); // Sync method in async context!

return post;
}

// ❌ Even worse - blocking async code
public BlogPost GetPost(int id)
{
    return _context.BlogPosts
        .FirstOrDefaultAsync(p => p.Id == id)
        .Result;  // DEADLOCK RISK!
}
```

**समाधान**

```csharp
// ✅ Use async all the way
public async Task<BlogPost> GetPostAsync(int id)
{
 return await _context.BlogPosts
 .FirstOrDefaultAsync(p => p.Id == id);
}

// ✅ Or use sync all the way (not recommended for ASP.NET Core)
public BlogPost GetPost(int id)
{
    return _context.BlogPosts
        .FirstOrDefault(p => p.Id == id);
}
```

## ईएफ कोर 10: क्या है | ' | नए और तोड़ने वाले परिवर्तन

के साथ [ईएफ कोर 10](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-10.0/whatsnew) के साथ जारी किया गया .NET | 10, | वहाँ कई महत्वपूर्ण परिवर्तनों को अद्यतन करते समय ध्यान में रखना है [ईएफ कोर में परिवर्तनों को तोड़ना 10](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-10.0/breaking-changes).

### रनटाइम आवश्यकताएं

**कोर EF 10 की आवश्यकता है**यह .NET पर नहीं चलेगा. `net10.0` अद्यतन करने से पहले

### Query-Related Breaking Changes

#### पैरामीटर किए गए संग्रह अनुवाद (पूर्वनिर्धारित परिवर्तन किया गया

एफ कोर 10 कैसे बदलता है `Contains()` के साथ in-memory collections को SQL में अनुवादित किया जाता है `OpenJson()` (SQL सर्वर) या इसी प्रकार के **पैरामीटर एरे** जो बेहतर क्वेरी योजना कैचिंग प्रदान करते हैं

**प्रभाव**: आप विभिन्न SQL क्वेरी के लिए उत्पन्न देखा जा सकता है जैसे

```csharp
var ids = new List<int> { 1, 2, 3, 4, 5 };
var posts = await _context.BlogPosts
 .Where(p => ids.Contains(p.Id))
 .ToListAsync();
```

**ईएफ कोर**

```sql
SELECT b."Id", b."Title"
FROM "BlogPosts" AS b
WHERE b."Id" IN (SELECT value FROM OPENJSON(@__ids_0))
```

**ईएफ कोर 10 | ( | पैरामीटर एरे**

```sql
SELECT b."Id", b."Title"
FROM "BlogPosts" AS b
WHERE b."Id" = ANY(@__ids_0)  -- PostgreSQL
-- Or: WHERE b."Id" IN (@__ids_0_0, @__ids_0_1, @__ids_0_2, ...) -- SQL Server
```

**यदि आप निष्पादन ह्रास अनुभव करते हैं**पुराने व्यवहार में वापस जाएँ

```csharp
// SQL Server
optionsBuilder.UseSqlServer(connectionString,
    o => o.UseParameterizedCollectionMode(ParameterTranslationMode.Constant));

// PostgreSQL - generally parameter arrays work well, but you can opt out if needed
```

#### 2. ExecuteUpdateAsync हस्ताक्षर परिवर्तन

`ExecuteUpdateAsync` हस्ताक्षर को गैर समर्थन के लिए बदल दिया गया है -expression lambdas. यह अधिक लचीला है लेकिन **कोड को तोड़ता है जो प्रोग्रामिंग रूप से अभिव्यक्ति वृक्षों को बनाया गया**:

**पुराना तरीका (EF कोर 7-9):**

```csharp
// This still works
await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(p => p.IsArchived, true));
```

**ईएफ कोर में नया 10 - NonM SK2expression lambdas:**

```csharp
// Now you can include custom logic!
await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ExecuteUpdateAsync(setters =>
    {
        setters.SetProperty(p => p.IsArchived, true);
        setters.SetProperty(p => p.UpdatedAt, DateTime.UtcNow);
        // Can now include conditional logic, loops, etc.
    });
```

#### 3. जटिल प्रकार स्तम्भ नामकरण

ईएफ कोर 10 परिवर्तन करता है कि कैसे निहित जटिल प्रकार के स्तंभों को नामित किया जाता है ताकि डेटा खराबी से बचाया जा सके

**ईएफ कोर 9:**

```
NestedComplex_Property
```

**ईएफ कोर 10:**

```
OuterComplex_NestedComplex_Property
```

**प्रवासी प्रभाव**: यदि आपके पास जटिल प्रकार के मौजूदा तालिका हैं तो आपको स्तंभों का नाम बदलने या स्पष्ट स्तंभिक नाम कॉन्फ़िगर करने की आवश्यकता हो सकती है

```csharp
modelBuilder.Entity<Order>()
 .ComplexProperty(o => o.ShippingAddress)
 .Property(a => a.Street)
 .HasColumnName("ShippingAddress_Street"); // Explicit name
```

### एसक्यूएल सर्वर / Azure SQL विशेष परिवर्तन

#### डाटा प्रकार डिफ़ॉल्ट

**बहिष्कार करना** (if you need backwards compatibility

```csharp
optionsBuilder.UseAzureSql(connectionString,
    o => o.UseCompatibilityLevel(160)); // Use old NVARCHAR behavior
```

### जाँच सूची अद्यतन कर रहा है

EF कोर से 8/9 को EF कोर में अद्यतन करते समय

1. ✅ लक्ष्य फ्रेमवर्क को अद्यतन करें `net10.0`
2. सभी अद्यतन करें `Microsoft.EntityFrameworkCore.*` पैकेज को 10.x
3. अद्यतन `Npgsql.EntityFrameworkCore.PostgreSQL` के लिए 10.x
4. ✅ प्रयोग से प्रश्नों की समीक्षा `Contains()` प्रदर्शन परिवर्तन के लिए संग्रहों के साथ
5. ✅ किसी भी कोड को जाँचें जो प्रोग्रामात्मक रूप से बनाता है `ExecuteUpdateAsync` अभिव्यक्तियां
6. ✅ नीस्टेड कॉम्पलेक्स प्रकार का उपयोग करते हुए कॉम्पलीक्स प्रकार के स्तंभ नाम जाँचें
7. यदि Azure SQL का उपयोग कर रहा है तो एसक्यूएल सर्वर JSON स्तंभ उपयोग की समीक्षा करें

### क्या है?

- **उन्नत LINQ अनुवाद**जटिल क्वेरी के लिए बेहतर एसक्यूएल जनन
- **ExecuteUpdateAsync में Non-expression lambdas**: बल्क अद्यतन में अधिक लचीलापन
- **बेहतर पैरामीटर प्रबंधन**: बेहतर क्वेरी योजना कैचिंग
- **उन्नत JSON समर्थन**एसक्यूएल सर्वर पर मूल JSON प्रकार
- **निष्पादन सुधार**: तीव्र सामग्रीकरण और परिवर्तन ट्रैकिंग

## निष्पादन विशेषताएँ

- **क्वेरी निष्पादन**सामान्य क्वेरी के लिए डेपर की तुलना में : 20-50% ओवरहेड
- **स्मृति उपयोग**: परिवर्तन ट्रैकिंग और प्रॉक्सी जनन के कारण उच्च
- **पहला प्रश्न**: धीमी
- **अनुवर्ती प्रश्न**: संकलित क्वेरी कैश के कारण तेजी से
- **घुसाता है/Updates**: स्वचालित परिवर्तन ट्रैकिंग ओवरहेड जोड़ता है
- **बल्क ऑपरेशन**डिफ़ॉल्ट विधियों के साथ खराब निष्पादन [EFCore.BulkExtensions](https://github.com/borisdj/EFCore.BulkExtensions) या EF कोर में ExecuteUpdate/ExecuteDelete

## ईएफ कोर के लिए सर्वोत्तम प्रथाएं

### सामान्य दिशानिर्देश

1. **AsNoTracking का उपयोग करें** पढ़ने के लिए केवल क्वेरी read- स्मृति ओवरहेड को कम करने हेतु
2. **N+1 क्वेरी से बचें** उपयोग `Include()` या उचित रूप से क्वेरी विभाजित करें
3. **संकलित क्वेरी का उपयोग करें** बार-बार पूछने वाले पैटर्न के लिए
4. **के रूप में विचार करेंQuery()** जटिल के लिए कार्टेशियन उत्पादों से बचने के लिए शामिल है
5. **बैचिंग का उपयोग करें** बहुल प्रविष्टियों के लिए
6. **डीटीओ को परियोजना** डेटा अंतरण और स्मृति उपयोग को कम करने के लिए जल्दी
7. **लीवरेज ExecuteUpdate/ExecuteDelete** बल्क ऑपरेशन के लिए (EF कोर
8. **हमेशा लॉग और समीक्षा की गई एसक्यूएल** विकास में

### पोस्टग्रेएसक्यूएल के साथ काम करते समय

1. **पूरा -पाठ खोज प्रयोग करें** विशेषताएँ ([मेरा मार्गदर्शक](/blog/textsearchingpt1)) के बजाय `LIKE` प्रश्न
2. **JSONB स्तंभों को लेवरेज करें** लचीला स्कीमा के लिए
3. **à¤aà¥à¤°à¥‡à¤‚** इकाइयों के भीतर संग्रहण के लिए
4. **कनेक्शन पूलिंग कॉन्फ़िगर करें** अपने कार्यभार के लिए उचित
5. **अपनी अनुक्रमणिका `tsvector` स्तंभ** GIN अनुक्रमणिकाओं के साथ
6. **रेंज प्रकार इस्तेमाल करें** तारीख के लिए

## भाग में आ रहा है 2

अगले लेख में हम

- **डैपर**माइक्रोसॉफ्ट स्पॉट
- **कच्चा ADO.NET/Npgsql**: अधिकतम निष्पादन और नियंत्रण
- **ऑब्जेक्ट मैपिंग पुस्तकालय**: मैपस्टर vs ऑटोमापर
- **हाइब्रिड दृष्टिकोण**ईएफ कोर और डैपर का संयोजन
- **निष्पादन मानक**: वास्तविक
- **निर्णय मैट्रिक्स**: अपने परिदृश्य के लिए सही उपकरण चुनना

## संदर्भ और आगे पढ़ने

- [इकाई फ्रेमवर्क कोर दस्तावेज़ीकरण](https://learn.microsoft.com/en-us/ef/core/)
- [एनपीजीएसक्यूएल अस्तित्व फ्रेमवर्क कोर प्रदाता](https://www.npgsql.org/efcore/)
- [ईएफ कोर निष्पादन](https://learn.microsoft.com/en-us/ef/core/performance/)
- [ईएफ कोर में क्या नया है](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-10.0/whatsnew)
- [ईएफ कोर में परिवर्तनों को तोड़ना 10](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-10.0/breaking-changes)
- [ईएफ कोर में क्या नया है](https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-8.0/whatsnew)
- [पोस्टग्रेएसक्यूएल दस्तावेज़ीकरण](https://www.postgresql.org/docs/)

**इस ब्लॉग पर संबंधित लेख**

- [ब्लॉग पोस्ट के लिए अस्तित्व फ्रेमवर्क जोड़ना](/blog/addingentityframeworkforblogpostspt1)
- [ईएफ प्रवास सही रास्ते में](/blog/efmigrationstherightway)
- [ईएफ कोर के साथ पूर्ण पाठ खोज](/blog/textsearchingpt1)
- [आधुनिक सीक्यूआरएस और घटना खोज](/blog/moderncqrsandeventsourcing)

---

*भाग 2, में हम ' डैपर में प्रविष्ट करेंगें\,\ कच्चे Npgsql\,\ और यह पता लगाने के लिए कि कैसे अधिकतम निष्पादन तथा रख-रखावता के लिए बहुविध दृष्टिकोणों का संयोजन किया जा सकता है*

This is a preview from the server running through my markdig pipeline

.NET Database EF Core Performance PostgreSQL

डेटा अभिगम में .NET: ओआरएमों और मानचित्रण रणनीतियों का तुलना करना | ( | भाग |1 | \ - | अस्तित्व फ्रेमवर्क कोर

Wednesday, 03 December 2025

भाग 1 इकाई फ्रेमवर्क कोर पर ध्यान केंद्रित करता है भाग 2 Dapper, raw ADO.NETM SK2 object mapping libraries

विषयसूची

डेटा अभिगम दृष्टिकोणों की स्पेक्ट्रम

डेटा अभिगम परिदृश्य को एक स्पेक्ट्रम के रूप में दृश्यीकृत किया जा सकता है

Full Abstraction                                      Full Control
     ↓                                                      ↓
[EF Core] → [EF Core Raw SQL] → [Dapper] → [Npgsql ADO.NET]

डेटा एक्सेस फ्लो तुलना

graph TB
    subgraph "EF Core Flow"
        A1[LINQ Query] -->|Compile| B1[Expression Tree]
        B1 -->|Translate| C1[SQL Query]
        C1 -->|Execute| D1[PostgreSQL]
        D1 -->|Results| E1[DbDataReader]
        E1 -->|Materialize| F1[Tracked Entities]
        F1 -->|Return| G1[Application]
    end

    subgraph "Dapper Flow"
        A2[SQL String] -->|Parameterize| B2[DbCommand]
        B2 -->|Execute| C2[PostgreSQL]
        C2 -->|Results| D2[DbDataReader]
        D2 -->|Map| E2[POCOs]
        E2 -->|Return| F2[Application]
    end

    subgraph "Raw Npgsql Flow"
        A3[SQL + Parameters] -->|Build Command| B3[NpgsqlCommand]
        B3 -->|Execute| C3[PostgreSQL]
        C3 -->|Results| D3[NpgsqlDataReader]
        D3 -->|Manual Mapping| E3[Objects]
        E3 -->|Return| F3[Application]
    end

    style A1 stroke:#2563eb,stroke-width:2px
    style B1 stroke:#2563eb,stroke-width:2px
    style C1 stroke:#2563eb,stroke-width:2px
    style D1 stroke:#2563eb,stroke-width:2px
    style E1 stroke:#2563eb,stroke-width:2px
    style F1 stroke:#2563eb,stroke-width:2px
    style G1 stroke:#2563eb,stroke-width:2px

    style A2 stroke:#059669,stroke-width:2px
    style B2 stroke:#059669,stroke-width:2px
    style C2 stroke:#059669,stroke-width:2px
    style D2 stroke:#059669,stroke-width:2px
    style E2 stroke:#059669,stroke-width:2px
    style F2 stroke:#059669,stroke-width:2px

    style A3 stroke:#dc2626,stroke-width:2px
    style B3 stroke:#dc2626,stroke-width:2px
    style C3 stroke:#dc2626,stroke-width:2px
    style D3 stroke:#dc2626,stroke-width:2px
    style E3 stroke:#dc2626,stroke-width:2px
    style F3 stroke:#dc2626,stroke-width:2px

निष्पादन विपरीत विकासकर्ता उत्पादकता व्यापार

graph LR
    A[High Productivity<br/>Low Performance] --> B[EF Core<br/>Full Tracking]
    B --> C[EF Core<br/>No Tracking]
    C --> D[EF Core<br/>Raw SQL]
    D --> E[Dapper]
    E --> F[Raw Npgsql]
    F --> G[Low Productivity<br/>High Performance]

    style A stroke:#2563eb,stroke-width:2px
    style B stroke:#2563eb,stroke-width:2px
    style C stroke:#3b82f6,stroke-width:2px
    style D stroke:#059669,stroke-width:2px
    style E stroke:#059669,stroke-width:2px
    style F stroke:#dc2626,stroke-width:2px
    style G stroke:#dc2626,stroke-width:2px

अस्तित्व फ्रेमवर्क कोर

इकाई फ्रेमवर्क कोर है माइक्रोसॉफ्ट'स् फ्लैगशिप ORM, आपके डेटाबेस पर एक पूर्ण अमूर्ति प्रदान करता है Npgsql.EntityFrameworkCore.PostgreSQL प्रदाता.

अपने परियोजना में ईएफ कोर को स्थापित करने के लिए व्यावहारिक मार्गदर्शन हेतु ब्लॉग पोस्ट के लिए अस्तित्व फ्रेमवर्क जोड़ना.

मुख्य विशेषताएँ

ट्रैकिंग बदलें: स्वचालित रूप से इकाई परिवर्तनों को ट्रैक करता है और उपयुक्त SQL उत्पन्न करता है
प्रवासकोड ईएफ प्रवास सही रास्ते में)
LINQ प्रदाता: प्रकार
लचीला/अत्यावश्यक लोड: संबंधित इकाइयों के लिए लचीला लोडिंग रणनीति
उन्नत PostgreSQL विशेषताएँपूर्णमेरा लेख देखें), JSON स्तंभों
अवरोधक और घटनाएँ: Cross--cutting चिंताओं के लिए विस्तार बिंदु

उदाहरण: EF कोर के साथ बुनियादी CRUD

public class BlogDbContext : DbContext
{
    public DbSet<BlogPost> BlogPosts { get; set; }
    public DbSet<Comment> Comments { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseNpgsql("Host=localhost;Database=blog;Username=postgres;Password=secret");
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // PostgreSQL-specific: Full-text search
        modelBuilder.Entity<BlogPost>()
            .HasGeneratedTsVectorColumn(
                p => p.SearchVector,
                "english",
                p => new { p.Title, p.Content })
            .HasIndex(p => p.SearchVector)
            .HasMethod("GIN");

        // PostgreSQL array type
        modelBuilder.Entity<BlogPost>()
            .Property(p => p.Tags)
            .HasPostgresArrayConversion(
                tag => tag.ToLowerInvariant(),
                tag => tag);
    }
}

public class BlogPost
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
    public string[] Tags { get; set; }
    public NpgsqlTsVector SearchVector { get; set; }
    public List<Comment> Comments { get; set; }
    public DateTime PublishedDate { get; set; }
}

// Usage
public class BlogService
{
    private readonly BlogDbContext _context;

    public async Task<List<BlogPost>> GetRecentPostsAsync(int count)
    {
        return await _context.BlogPosts
            .Include(p => p.Comments)
            .OrderByDescending(p => p.PublishedDate)
            .Take(count)
            .ToListAsync();
    }

    public async Task<List<BlogPost>> SearchPostsAsync(string searchTerm)
    {
        return await _context.BlogPosts
            .Where(p => p.SearchVector.Matches(EF.Functions.ToTsQuery("english", searchTerm)))
            .ToListAsync();
    }

    public async Task AddPostAsync(BlogPost post)
    {
        _context.BlogPosts.Add(post);
        await _context.SaveChangesAsync();
    }
}

रॉ SQL के साथ ईएफ कोर

public async Task<List<BlogPost>> GetPostsByComplexCriteriaAsync()
{
    var searchTerm = "postgresql";

    return await _context.BlogPosts
        .FromSqlInterpolated($@"
            SELECT * FROM ""BlogPosts""
            WHERE ""SearchVector"" @@ to_tsquery('english', {searchTerm})
            AND array_length(""Tags"", 1) > 3
            ORDER BY ts_rank(""SearchVector"", to_tsquery('english', {searchTerm})) DESC
        ")
        .ToListAsync();
}

// Or with DbDataReader for maximum control
public async Task<List<PostStatistics>> GetPostStatisticsAsync()
{
    using var command = _context.Database.GetDbConnection().CreateCommand();
    command.CommandText = @"
        SELECT
            DATE_TRUNC('month', ""PublishedDate"") as Month,
            COUNT(*) as PostCount,
            AVG(ARRAY_LENGTH(""Tags"", 1)) as AvgTags
        FROM ""BlogPosts""
        GROUP BY DATE_TRUNC('month', ""PublishedDate"")
        ORDER BY Month DESC";

    await _context.Database.OpenConnectionAsync();

    var results = new List<PostStatistics>();
    using var reader = await command.ExecuteReaderAsync();

    while (await reader.ReadAsync())
    {
        results.Add(new PostStatistics
        {
            Month = reader.GetDateTime(0),
            PostCount = reader.GetInt32(1),
            AverageTags = reader.GetDouble(2)
        });
    }

    return results;
}

ईएफ कोर को कब प्रयोग करना है

EF कोर का उपयोग करें जब

विकासशील स्कीमा आवश्यकताओं के साथ एक नया अनुप्रयोग बनाना
आपको मजबूत टाइपिंग और कम्पाइल की जरूरत है
माइग्रेसन और स्कीमा संस्करणिंग महत्वपूर्ण हैं मेरी प्रवासी मार्गदर्शक)
आपकी टीम SQL से अधिक ऑब्जेक्टों के साथ काम करना पसंद करती है
आप संबंधों के साथ जटिल डोमेन मॉडल का उपयोग कर रहे हैं
विकास गति कच्चे निष्पादन से अधिक महत्वपूर्ण है
आप को cross-डेटाबेस पोर्टेबलता की आवश्यकता है।

EF कोर से बचें जब

अधिकतम निष्पादन महत्वपूर्ण है
आपके पास जटिल,hand-tuned SQL क्वेरी हैं
आपकी क्वेरी ग्राफ्स ऑब्जेक्ट के लिए अच्छी तरह से नक्शे नहीं map
आपको प्रत्येक एसक्यूएल कथन पर fine-रक्षित नियंत्रण की जरूरत है
स्मृति उपयोग एक महत्वपूर्ण अवरोध है
आप ''' legacy schemas के साथ काम कर रहे हैं जो don''' conventions में नक्शा नहीं

ईएफ कोर एसक्यूएल जेनरेशन

Generated SQL को देख रहा है

// Enable sensitive data logging and detailed errors (development only!)
optionsBuilder
    .UseNpgsql(connectionString)
    .EnableSensitiveDataLogging()
    .EnableDetailedErrors()
    .LogTo(Console.WriteLine, LogLevel.Information);

// Or use logging to see SQL
public class BlogService
{
    private readonly BlogDbContext _context;
    private readonly ILogger<BlogService> _logger;

    public async Task<List<BlogPost>> GetPostsAsync()
    {
        var query = _context.BlogPosts
            .Where(p => p.PublishedDate > DateTime.UtcNow.AddDays(-30))
            .OrderByDescending(p => p.PublishedDate);

        // View the SQL before execution
        var sql = query.ToQueryString();
        _logger.LogInformation("Executing query: {Sql}", sql);

        return await query.ToListAsync();
    }
}

उदाहरण: साधारण क्वेरी

C# LINQ

var recentPosts = await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .OrderByDescending(p => p.PublishedDate)
    .Take(10)
    .ToListAsync();

Generated SQL (ईएफ कोर 8+):

SELECT b."Id", b."Title", b."Content", b."CategoryId", b."PublishedDate"
FROM "BlogPosts" AS b
WHERE b."CategoryId" = @__categoryId_0
ORDER BY b."PublishedDate" DESC
LIMIT @__p_1

ध्यान दें कि कैसे एफ कोर 8+ उचित पैरामीटरीकरण के साथ स्वच्छ, कुशल SQL उत्पन्न करता है ईएफ कोर 10 इस प्रवृत्ति को और अधिक सुधार के साथ जारी रखता है

उदाहरण: शामिल करने के साथ जोड़ें | ( | EF कोर से पहले

कोड

var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .ToListAsync();

पुराना एसक्यूएल (EF कोर

SELECT b."Id", b."Title", c."Id", c."Name", cm."Id", cm."Content"
FROM "BlogPosts" AS b
LEFT JOIN "Categories" AS c ON b."CategoryId" = c."Id"
LEFT JOIN "Comments" AS cm ON b."Id" = cm."BlogPostId"
ORDER BY b."Id", c."Id"

यह एक बनाता है कार्टेशियन उत्पाद यदि एक पोस्ट में 10 टिप्पणी है तो यह पंक्ति दोहराया जाता है

उदाहरण: विभाजित क्वेरी

Split Query के साथ कोड

var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .AsSplitQuery()  // ← This is the key!
    .ToListAsync();

Generated SQL (Multiple Queries):

-- Query 1: Get posts and categories
SELECT b."Id", b."Title", b."Content", c."Id", c."Name"
FROM "BlogPosts" AS b
LEFT JOIN "Categories" AS c ON b."CategoryId" = c."Id"

-- Query 2: Get comments for those posts
SELECT cm."Id", cm."Content", cm."BlogPostId"
FROM "Comments" AS cm
INNER JOIN (
    SELECT b."Id"
    FROM "BlogPosts" AS b
) AS t ON cm."BlogPostId" = t."Id"
ORDER BY t."Id"

यह कार्टेशियन उत्पाद को समाप्त करता है और प्रायः अधिक तेजी से संग्रह के लिए

उदाहरण: फिल्टर किए गए में शामिल है (EF कोर 5+)

कोड

var posts = await _context.BlogPosts
    .Include(p => p.Comments.Where(c => c.IsApproved))
    .ToListAsync();

बनाया गया SQL:

SELECT b."Id", b."Title", b."Content", t."Id", t."Content", t."IsApproved"
FROM "BlogPosts" AS b
LEFT JOIN (
    SELECT c."Id", c."Content", c."IsApproved", c."BlogPostId"
    FROM "Comments" AS c
    WHERE c."IsApproved" = TRUE
) AS t ON b."Id" = t."BlogPostId"
ORDER BY b."Id"

उदाहरण: JSON स्तम्भ क्वेरी

कोड

public class BlogPost
{
    public int Id { get; set; }
    public string Title { get; set; }
    public PostMetadata Metadata { get; set; }  // Stored as JSONB
}

public class PostMetadata
{
    public bool IsFeatured { get; set; }
    public int ViewCount { get; set; }
    public List<string> RelatedTags { get; set; }
}

// Query JSON properties
var featuredPosts = await _context.BlogPosts
    .Where(p => p.Metadata.IsFeatured)
    .ToListAsync();

बनाया गया SQL:

SELECT b."Id", b."Title", b."Metadata"
FROM "BlogPosts" AS b
WHERE b."Metadata" ->> 'IsFeatured' = 'true'

EF कोर 7+ PostgreSQL JSON ऑपरेटरों के लिए JSON गुण अभिगम का अनुवाद कर सकता है

उदाहरण: बल्क अद्यतन (EF कोर | 7+ | निष्पादित अद्यतन

पुराना तरीका (अक्षम

var posts = await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ToListAsync();

foreach (var post in posts)
{
    post.IsArchived = true;
}

await _context.SaveChangesAsync();  // Generates N UPDATE statements!

नया रास्ता

await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(p => p.IsArchived, true));

Generated SQL (Single Query!):

UPDATE "BlogPosts" AS b
SET "IsArchived" = TRUE
WHERE b."CategoryId" = 5

यह एक है विशाल सुधार - एक एसक्यूएल कथन N के बजाय

उदाहरण: बल्क मिटाएँ (EF कोर 7+)

ओल्ड वे

var oldPosts = await _context.BlogPosts
    .Where(p => p.PublishedDate < DateTime.UtcNow.AddYears(-5))
    .ToListAsync();

_context.BlogPosts.RemoveRange(oldPosts);
await _context.SaveChangesAsync();  // N DELETE statements

नया रास्ता

await _context.BlogPosts
    .Where(p => p.PublishedDate < DateTime.UtcNow.AddYears(-5))
    .ExecuteDeleteAsync();

बनाया गया SQL:

DELETE FROM "BlogPosts" AS b
WHERE b."PublishedDate" < @__p_0

उदाहरण: जटिल समूह

कोड

var categoryStats = await _context.Categories
    .Select(c => new CategoryStats
    {
        CategoryName = c.Name,
        PostCount = c.BlogPosts.Count(),
        LatestPostDate = c.BlogPosts.Max(p => p.PublishedDate),
        AverageComments = c.BlogPosts.Average(p => p.Comments.Count)
    })
    .ToListAsync();

Generated SQL (EF Core 8+/10):

SELECT c."Name" AS "CategoryName",
       COUNT(*)::int AS "PostCount",
       MAX(b."PublishedDate") AS "LatestPostDate",
       COALESCE(AVG((
           SELECT COUNT(*)::int
           FROM "Comments" AS c0
           WHERE b."Id" = c0."BlogPostId"
       ))::double precision, 0.0) AS "AverageComments"
FROM "Categories" AS c
LEFT JOIN "BlogPosts" AS b ON c."Id" = b."CategoryId"
GROUP BY c."Id", c."Name"

पोस्टग्रेएसक्यूएल पूर्ण

अधिक गहराई के लिए पूरा ढूंढें ईएफ कोर के साथ पूरा पाठ खोज लागू करना.

कोड

var searchResults = await _context.BlogPosts
    .Where(p => p.SearchVector.Matches(EF.Functions.ToTsQuery("english", "postgresql & performance")))
    .OrderByDescending(p => p.SearchVector.Rank(EF.Functions.ToTsQuery("english", "postgresql & performance")))
    .Take(20)
    .ToListAsync();

बनाया गया SQL:

SELECT b."Id", b."Title", b."Content", b."SearchVector"
FROM "BlogPosts" AS b
WHERE b."SearchVector" @@ to_tsquery('english', @__searchTerm_0)
ORDER BY ts_rank(b."SearchVector", to_tsquery('english', @__searchTerm_0)) DESC
LIMIT 20

Critical EF Core Warnings and Pitfalls

1. ट्रैकिंग मेमोरी लीक बदलें

समस्या

// ❌ DANGER: This can cause memory leaks!
public class PostCache
{
    private readonly BlogDbContext _context;
    private List<BlogPost> _cachedPosts;

    public PostCache(BlogDbContext context)
    {
        _context = context;
    }

    public async Task LoadCacheAsync()
    {
        // These entities are now tracked by the context
        _cachedPosts = await _context.BlogPosts.ToListAsync();

        // The DbContext holds references to these entities FOREVER
        // They can never be garbage collected while the context lives!
    }
}

क्या यह एक समस्या है

ट्रैक किए गए अस्तित्वों का जीवनकाल के लिए स्मृति में रहते हैं DbContext
परिवर्तन ट्रैकर संदर्भ रखता है
लम्बे -जीवन संदर्भ (e.gM SK3 एकलटन SSK4 = स्मृति लीक
ASP में .NET Core, संदर्भ पूर्वनिर्धारित रूप से स्कोप किया जाता है
लेकिन यदि आप कैश ट्रैक किए गए इकाइयों को खींचते हैं, आप' समस्या में है

समाधान

public async Task LoadCacheAsync()
{
    // ✅ Use AsNoTracking() for read-only queries
    _cachedPosts = await _context.BlogPosts
        .AsNoTracking()
        .ToListAsync();

    // Or detach entities after loading
    var posts = await _context.BlogPosts.ToListAsync();
    foreach (var post in posts)
    {
        _context.Entry(post).State = EntityState.Detached;
    }
    _cachedPosts = posts;
}

2. प्रॉक्सी जनन और लचीले लोडिंग खतरा

🚨 क्रिटिकल चेतावनी

लचीला लोडिंग प्रॉक्सी गारंटीकृत स्मृति लीक

यदि आप क्यास DbContext इंस्टैंस या क्यास एंटिटीज सक्रिय proxies के साथ लोड किया है WILL लीक मेमोरी. प्रॉक्सी तंत्र डीबी संदर्भ के संदर्भों को बनाए रखता है।

अंगूठी नियम: हमेशा संग्रहों को स्पष्ट रूप से साथ शामिल करें .Include(). केवल प्रॉक्सी का उपयोग करें यदि आप सौदाओं को पूरी तरह समझते हैं और कभी भी नहीं

समस्या 1: The N+1 Query Nightmare

// ❌ Enable lazy loading
optionsBuilder
    .UseNpgsql(connectionString)
    .UseLazyLoadingProxies();  // Convenient but dangerous!

public class BlogPost
{
    public int Id { get; set; }
    public string Title { get; set; }
    public virtual Category Category { get; set; }  // Virtual = proxy
    public virtual List<Comment> Comments { get; set; }
}

// Somewhere in your code
var posts = await _context.BlogPosts.ToListAsync();

foreach (var post in posts)
{
    Console.WriteLine(post.Category.Name);  // N+1 query here!
    Console.WriteLine(post.Comments.Count);  // Another N+1 query!
}

क्या होता है

पहला क्वेरी सभी पोस्ट लोड करता है
के लिए प्रत्येक पदअभिगम Category एक डाटाबेस क्वेरी ट्रिगर करता है
के लिए प्रत्येक पदअभिगम Comments एक और क्वेरी ट्रिगर करता है
यदि आपके पास 100 पोस्ट है 201 प्रश्न!

समस्या 2: प्रॉक्सी + कैचिंग = मेमोरी लीक

// ❌ CATASTROPHIC: Lazy loading proxies + caching
public class BlogPostCache
{
    private static List<BlogPost> _cachedPosts;
    private readonly BlogDbContext _context;

    public BlogPostCache()
    {
        var optionsBuilder = new DbContextOptionsBuilder<BlogDbContext>();
        optionsBuilder
            .UseNpgsql(connectionString)
            .UseLazyLoadingProxies();  // ⚠️ DANGER!

        _context = new BlogDbContext(optionsBuilder.Options);
    }

    public async Task<List<BlogPost>> GetCachedPostsAsync()
    {
        if (_cachedPosts == null)
        {
            // ❌ These proxy entities hold references to _context
            _cachedPosts = await _context.BlogPosts.ToListAsync();
        }
        return _cachedPosts;
    }
}

यह विनाशकारी क्यों है

प्रॉक्सी इकाइयां अपने DbContext
DbContext सभी ट्रैक किए गए इकाइयों के लिए संदर्भ रखता है
आपका कैश अब संपूर्ण वस्तु ग्राफ को कचरा डाक एकत्रित होने से रोकता है
हर बार जब आप एक नेविगेशन गुण अभिगम करता है, यह क्वेरी ट्रिगर कर सकता है के उपयोग से पुराना, कैश संदर्भ
जब आप अधिक डेटा लोड करते हैं, स्मृति बिना सीमाओं के बढ़ती है
आप अंततः मेमोरी या बाहरी कनेक्शन पूलों से बाहर चला जाएगा

समाधान: स्पष्ट होना

// ✅ NEVER use lazy loading proxies - always be explicit
optionsBuilder
    .UseNpgsql(connectionString);
    // NO .UseLazyLoadingProxies()!

public class BlogPost
{
    public int Id { get; set; }
    public string Title { get; set; }
    public Category Category { get; set; }  // NOT virtual
    public List<Comment> Comments { get; set; }  // NOT virtual
}

// ✅ Explicit eager loading - you control what's loaded
var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .ToListAsync();

// ✅ Or use split queries for better performance
var posts = await _context.BlogPosts
    .Include(p => p.Category)
    .Include(p => p.Comments)
    .AsSplitQuery()
    .ToListAsync();

// ✅ Or use projection to DTOs (best for caching)
var posts = await _context.BlogPosts
    .Select(p => new PostDto
    {
        Title = p.Title,
        CategoryName = p.Category.Name,
        CommentCount = p.Comments.Count
    })
    .ToListAsync();

// ✅ If you MUST cache, use AsNoTracking and no proxies
public class SafeBlogPostCache
{
    private static List<BlogPost> _cachedPosts;
    private readonly IDbContextFactory<BlogDbContext> _contextFactory;

    public async Task<List<BlogPost>> GetCachedPostsAsync()
    {
        if (_cachedPosts == null)
        {
            using var context = await _contextFactory.CreateDbContextAsync();

            _cachedPosts = await context.BlogPosts
                .Include(p => p.Category)
                .Include(p => p.Comments)
                .AsNoTracking()  // Critical for caching!
                .ToListAsync();
        }
        return _cachedPosts;
    }
}

जब प्रॉक्सी स्वीकार्य हो सकता है (ट्रेडऑफ्स को समझें

लचीले लोडिंग प्रॉक्सी तभी स्वीकार्य हो सकते हैं जब

✅ आपको छोटा-जीवन स्कोपित संदर्भ प्रति HTTP अनुरोध
✅You कभी नहीं कैश इकाइयों
@info: whatsthis
✅ आप' prototyping कर रहे हैं और बाद में अनुकूलन करेंगे
✅ आपकी टीम पूरी तरह से implications समझता है

लेकिन फिर भी Include() लगभग हमेशा बेहतर विकल्प है क्योंकि

यह डाटा लोड करता है स्पष्ट और स्पष्ट
एमएसके0 अनुकूलित करने में आसान आप देख सकते हैं कि क्या लोड किया जा रहा है
यह अनियमित N+1 प्रश्नों को रोकता है
यह कैशिंग और दीर्घ---जीवन संदर्भों के साथ सही काम करता है
यह' है सिफारिशित दृष्टिकोण एफ कोर टीम द्वारा

3. डीबी संदर्भ जीवनकाल मुद्दे

उत्पादन में डीबी कंटेक्स्ट जीवनकाल के प्रबंधन पर अधिक जानकारी के लिए ईएफ प्रवास सही रास्ते में.

समस्या

// ❌ NEVER do this - singleton DbContext
public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<BlogDbContext>();  // WRONG!
}

// ❌ Also wrong - storing context in static field
public static class DataAccess
{
    private static BlogDbContext _context = new BlogDbContext();

    public static async Task<BlogPost> GetPostAsync(int id)
    {
        return await _context.BlogPosts.FindAsync(id);
    }
}

क्या यह गलत है

DbContext है थ्रेड नहीं है
समवर्ती अनुरोधों से डेटा खराब हो जाएगा
परिवर्तन ट्रैकर अपरिभाषित रूप से बढ़ता है
कनेक्शन पूल समाप्ति
कैश से डाटा रोकें

समाधान

// ✅ Use scoped lifetime (default in ASP.NET Core)
public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<BlogDbContext>(options =>
        options.UseNpgsql(connectionString));
}

// ✅ Or use DbContext factory for background services
public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContextFactory<BlogDbContext>(options =>
        options.UseNpgsql(connectionString));
}

public class BlogBackgroundService
{
    private readonly IDbContextFactory<BlogDbContext> _contextFactory;

    public async Task ProcessPostsAsync()
    {
        // Create a new context for this operation
        using var context = await _contextFactory.CreateDbContextAsync();

        var posts = await context.BlogPosts.ToListAsync();
        // Process posts...
    }
}

4. अनपेक्षित नेविगेशन गुणों में शामिल है

समस्या

public class BlogPost
{
    public int Id { get; set; }
    public string Title { get; set; }
    public List<Comment> Comments { get; set; }
}

// You query one post...
var post = await _context.BlogPosts.FirstAsync();

// Add a new comment
var newComment = new Comment { Content = "Great post!" };
post.Comments.Add(newComment);

await _context.SaveChangesAsync();

// ❌ EF Core saves the comment, BUT...
// If Comments wasn't loaded, you just lost all existing comments!
// The collection is empty, so EF thinks there are no other comments

समाधान

// ✅ Always load navigation properties before modifying
var post = await _context.BlogPosts
    .Include(p => p.Comments)
    .FirstAsync(p => p.Id == postId);

post.Comments.Add(newComment);
await _context.SaveChangesAsync();

// Or add directly to the DbSet
_context.Comments.Add(new Comment
{
    BlogPostId = postId,
    Content = "Great post!"
});
await _context.SaveChangesAsync();

5. समन्वयन विपरीत समन्वयन मिक्सिंग

समस्या

// ❌ Mixing sync and async - deadlock risk!
public async Task<BlogPost> GetPostAsync(int id)
{
    var post = _context.BlogPosts
        .Where(p => p.Id == id)
        .FirstOrDefault();  // Sync method in async context!

    return post;
}

// ❌ Even worse - blocking async code
public BlogPost GetPost(int id)
{
    return _context.BlogPosts
        .FirstOrDefaultAsync(p => p.Id == id)
        .Result;  // DEADLOCK RISK!
}

समाधान

// ✅ Use async all the way
public async Task<BlogPost> GetPostAsync(int id)
{
    return await _context.BlogPosts
        .FirstOrDefaultAsync(p => p.Id == id);
}

// ✅ Or use sync all the way (not recommended for ASP.NET Core)
public BlogPost GetPost(int id)
{
    return _context.BlogPosts
        .FirstOrDefault(p => p.Id == id);
}

ईएफ कोर 10: क्या है | ' | नए और तोड़ने वाले परिवर्तन

के साथ ईएफ कोर 10 के साथ जारी किया गया .NET | 10, | वहाँ कई महत्वपूर्ण परिवर्तनों को अद्यतन करते समय ध्यान में रखना है ईएफ कोर में परिवर्तनों को तोड़ना 10.

रनटाइम आवश्यकताएं

कोर EF 10 की आवश्यकता हैयह .NET पर नहीं चलेगा. net10.0 अद्यतन करने से पहले

पैरामीटर किए गए संग्रह अनुवाद (पूर्वनिर्धारित परिवर्तन किया गया

एफ कोर 10 कैसे बदलता है Contains() के साथ in-memory collections को SQL में अनुवादित किया जाता है OpenJson() (SQL सर्वर) या इसी प्रकार के पैरामीटर एरे जो बेहतर क्वेरी योजना कैचिंग प्रदान करते हैं

प्रभाव: आप विभिन्न SQL क्वेरी के लिए उत्पन्न देखा जा सकता है जैसे

var ids = new List<int> { 1, 2, 3, 4, 5 };
var posts = await _context.BlogPosts
    .Where(p => ids.Contains(p.Id))
    .ToListAsync();

ईएफ कोर

SELECT b."Id", b."Title"
FROM "BlogPosts" AS b
WHERE b."Id" IN (SELECT value FROM OPENJSON(@__ids_0))

ईएफ कोर 10 | ( | पैरामीटर एरे

SELECT b."Id", b."Title"
FROM "BlogPosts" AS b
WHERE b."Id" = ANY(@__ids_0)  -- PostgreSQL
-- Or: WHERE b."Id" IN (@__ids_0_0, @__ids_0_1, @__ids_0_2, ...) -- SQL Server

यदि आप निष्पादन ह्रास अनुभव करते हैंपुराने व्यवहार में वापस जाएँ

// SQL Server
optionsBuilder.UseSqlServer(connectionString,
    o => o.UseParameterizedCollectionMode(ParameterTranslationMode.Constant));

// PostgreSQL - generally parameter arrays work well, but you can opt out if needed

2. ExecuteUpdateAsync हस्ताक्षर परिवर्तन

ExecuteUpdateAsync हस्ताक्षर को गैर समर्थन के लिए बदल दिया गया है -expression lambdas. यह अधिक लचीला है लेकिन कोड को तोड़ता है जो प्रोग्रामिंग रूप से अभिव्यक्ति वृक्षों को बनाया गया:

पुराना तरीका (EF कोर 7-9):

// This still works
await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(p => p.IsArchived, true));

ईएफ कोर में नया 10 - NonM SK2expression lambdas:

// Now you can include custom logic!
await _context.BlogPosts
    .Where(p => p.CategoryId == 5)
    .ExecuteUpdateAsync(setters =>
    {
        setters.SetProperty(p => p.IsArchived, true);
        setters.SetProperty(p => p.UpdatedAt, DateTime.UtcNow);
        // Can now include conditional logic, loops, etc.
    });

3. जटिल प्रकार स्तम्भ नामकरण

ईएफ कोर 9:

NestedComplex_Property

ईएफ कोर 10:

OuterComplex_NestedComplex_Property

प्रवासी प्रभाव: यदि आपके पास जटिल प्रकार के मौजूदा तालिका हैं तो आपको स्तंभों का नाम बदलने या स्पष्ट स्तंभिक नाम कॉन्फ़िगर करने की आवश्यकता हो सकती है

modelBuilder.Entity<Order>()
    .ComplexProperty(o => o.ShippingAddress)
    .Property(a => a.Street)
    .HasColumnName("ShippingAddress_Street"); // Explicit name

एसक्यूएल सर्वर / Azure SQL विशेष परिवर्तन

डाटा प्रकार डिफ़ॉल्ट

बहिष्कार करना (if you need backwards compatibility

optionsBuilder.UseAzureSql(connectionString,
    o => o.UseCompatibilityLevel(160)); // Use old NVARCHAR behavior

जाँच सूची अद्यतन कर रहा है

EF कोर से 8/9 को EF कोर में अद्यतन करते समय

✅ लक्ष्य फ्रेमवर्क को अद्यतन करें net10.0
सभी अद्यतन करें Microsoft.EntityFrameworkCore.* पैकेज को 10.x
अद्यतन Npgsql.EntityFrameworkCore.PostgreSQL के लिए 10.x
✅ प्रयोग से प्रश्नों की समीक्षा Contains() प्रदर्शन परिवर्तन के लिए संग्रहों के साथ
✅ किसी भी कोड को जाँचें जो प्रोग्रामात्मक रूप से बनाता है ExecuteUpdateAsync अभिव्यक्तियां
✅ नीस्टेड कॉम्पलेक्स प्रकार का उपयोग करते हुए कॉम्पलीक्स प्रकार के स्तंभ नाम जाँचें
यदि Azure SQL का उपयोग कर रहा है तो एसक्यूएल सर्वर JSON स्तंभ उपयोग की समीक्षा करें

क्या है?

उन्नत LINQ अनुवादजटिल क्वेरी के लिए बेहतर एसक्यूएल जनन
ExecuteUpdateAsync में Non-expression lambdas: बल्क अद्यतन में अधिक लचीलापन
बेहतर पैरामीटर प्रबंधन: बेहतर क्वेरी योजना कैचिंग
उन्नत JSON समर्थनएसक्यूएल सर्वर पर मूल JSON प्रकार
निष्पादन सुधार: तीव्र सामग्रीकरण और परिवर्तन ट्रैकिंग

निष्पादन विशेषताएँ

क्वेरी निष्पादनसामान्य क्वेरी के लिए डेपर की तुलना में : 20-50% ओवरहेड
स्मृति उपयोग: परिवर्तन ट्रैकिंग और प्रॉक्सी जनन के कारण उच्च
पहला प्रश्न: धीमी
अनुवर्ती प्रश्न: संकलित क्वेरी कैश के कारण तेजी से
घुसाता है/Updates: स्वचालित परिवर्तन ट्रैकिंग ओवरहेड जोड़ता है
बल्क ऑपरेशनडिफ़ॉल्ट विधियों के साथ खराब निष्पादन EFCore.BulkExtensions या EF कोर में ExecuteUpdate/ExecuteDelete

ईएफ कोर के लिए सर्वोत्तम प्रथाएं

सामान्य दिशानिर्देश

AsNoTracking का उपयोग करें पढ़ने के लिए केवल क्वेरी read- स्मृति ओवरहेड को कम करने हेतु
N+1 क्वेरी से बचें उपयोग Include() या उचित रूप से क्वेरी विभाजित करें
संकलित क्वेरी का उपयोग करें बार-बार पूछने वाले पैटर्न के लिए
के रूप में विचार करेंQuery() जटिल के लिए कार्टेशियन उत्पादों से बचने के लिए शामिल है
बैचिंग का उपयोग करें बहुल प्रविष्टियों के लिए
डीटीओ को परियोजना डेटा अंतरण और स्मृति उपयोग को कम करने के लिए जल्दी
लीवरेज ExecuteUpdate/ExecuteDelete बल्क ऑपरेशन के लिए (EF कोर
हमेशा लॉग और समीक्षा की गई एसक्यूएल विकास में

पोस्टग्रेएसक्यूएल के साथ काम करते समय

पूरा -पाठ खोज प्रयोग करें विशेषताएँ (मेरा मार्गदर्शक) के बजाय LIKE प्रश्न
JSONB स्तंभों को लेवरेज करें लचीला स्कीमा के लिए
à¤aà¥à¤°à¥à¤ इकाइयों के भीतर संग्रहण के लिए
कनेक्शन पूलिंग कॉन्फ़िगर करें अपने कार्यभार के लिए उचित
अपनी अनुक्रमणिका tsvector स्तंभ GIN अनुक्रमणिकाओं के साथ
रेंज प्रकार इस्तेमाल करें तारीख के लिए

भाग में आ रहा है 2

अगले लेख में हम

डैपरमाइक्रोसॉफ्ट स्पॉट
कच्चा ADO.NET/Npgsql: अधिकतम निष्पादन और नियंत्रण
ऑब्जेक्ट मैपिंग पुस्तकालय: मैपस्टर vs ऑटोमापर
हाइब्रिड दृष्टिकोणईएफ कोर और डैपर का संयोजन
निष्पादन मानक: वास्तविक
निर्णय मैट्रिक्स: अपने परिदृश्य के लिए सही उपकरण चुनना

संदर्भ और आगे पढ़ने

इस ब्लॉग पर संबंधित लेख

भाग 2, में हम ' डैपर में प्रविष्ट करेंगें,\ कच्चे Npgsql,\ और यह पता लगाने के लिए कि कैसे अधिकतम निष्पादन तथा रख-रखावता के लिए बहुविध दृष्टिकोणों का संयोजन किया जा सकता है