Video summary

C# Yazılım Dersleri 5-4 Repository Pattern ile uygulama geliştirmek.

Main summary

Key takeaways

Educational

Main ideas / concepts

  • Repository Pattern (as “extended layered architecture”)
    • Core problem: the UI/interface needs data in a different shape than how the database stores it.
    • Solution: introduce layers so data is:
      • retrieved from persistence,
      • processed/transformed,
      • and returned in a UI-friendly form.
    • This improves consistency and makes it easier to swap UI technology or storage technology later.

Layer responsibilities

  1. ORM / Entity Framework layer

    • Directly knows how to access the database.

  2. Repository layer

    • Retrieves data from the ORM.
    • Exposes CRUD-like methods to the service layer.
    • Hides ORM details from the rest of the application.

  3. Service layer

    • Converts repository results into DTOs.
    • Enforces a stable “contract” (what the UI can expect).
    • Can support different delivery mechanisms (e.g., web services, remoting, WCF), since it sits between UI and data.

  4. DTO layer

    • Contains the DTO classes used by the interface.
    • Organizes DTOs by purpose (e.g., product listing DTOs, product add DTOs).

Why DTOs

  • DTOs prevent the UI from dealing with raw entity/ORM types and database identifiers.
  • They allow the service to return exactly the fields needed by the interface.
    • Example: a product listing may include category/supplier names, not just their IDs.

Code First + Entity Framework 6 + tooling

  • The workflow discusses Code First and setting up EF 6:
    • Install Entity Framework 6 via NuGet.
    • Use Entity Framework Power Tools (reverse engineering / “DB model generation”) to reduce manual mapping.
  • It emphasizes that manual reverse engineering can be tedious; tooling helps generate entities, mappings, and configuration.

Generic repository + base repository

  • To avoid repeating Select/Insert/Update/Delete logic for every entity type:
    • Use a base repository class.
    • Use generics so methods operate on any entity type T.
  • The approach is described as a “convenience” architecture to reduce boilerplate.

Singleton pattern for DbContext

  • The ORM DbContext is accessed using a singleton-style method so repositories reuse the same context instance.
  • The speaker argues it reduces clutter/slowness by reusing a single context.
  • Note: in real web apps, per-request/per-session scoping is typically preferred.

Example domain

  • Uses a “Northwind”-style schema (North Wind project/database).
  • Mentions entities such as:
    • Products, Categories, Suppliers
    • Employees/Personnel
    • Orders
    • Order Details (sales details)

Methodology / step-by-step workflow (as presented)

1) Plan the layered solution structure

Create separate projects for:

  • Interface/UI (e.g., WinForms)
  • ORM / EF entities (Class Library, e.g., NorthWind.ORM)
  • Repository layer (Class Library)
  • Service layer (Class Library)
  • DTO layer (Class Library / DTO definitions)

2) Build the ORM layer (Entity Framework “Code First” workflow)

  • Add a Class Library to hold EF entities and mappings.
  • Install Entity Framework 6 via NuGet.
  • Use Entity Framework Power Tools to:
    • connect to the database,
    • generate entity classes and mapping configuration (Code First approach).

Result:

  • A Model folder containing entity classes and navigation properties (including concepts like lazy-loading via virtual collections).
  • A Mapping folder configuring tables/columns/relationships.

3) Test the ORM layer from the UI (temporary direct test)

  • Add a reference from the UI to the ORM project.
  • Use the generated DbContext to query entities.
  • Fix version mismatch if needed (ensure EF 6 is installed in the referencing project).
  • Verify data appears in the UI (e.g., in a DataGridView).

4) Introduce repository layer

  • Add a new Class Library: NorthRepository.
  • Define repositories with methods typically including:
    • Select/List
    • Insert/Add
    • Update
    • Delete

Repository behavior:

  • Call ORM/DbContext Set<T>()
  • Perform operations and call SaveChanges

Generic/base repository design:

  • Use a generic repository base class to handle CRUD for any entity type T.
  • Reduce repeated code via generics.

Singleton-style DbContext access:

  • A static get method returns the same context instance.

5) Create specific repositories per entity

  • Create entity-specific repositories inheriting from the base repository:
    • ProductsRepository, CategoriesRepository, SuppliersRepository, Personnel/EmployeesRepository
    • Sales/OrdersRepository, SalesDetailsRepository, etc.
  • Optionally add custom methods beyond CRUD (examples):
    • Exchange operation: increase/decrease product stock; handle receivables/payables.
    • Product fire/stock movement: record consumption/fire quantities.

6) Create the service layer

  • Add a new Class Library: Service.
  • Service responsibilities:
    • Call repository methods
    • Convert entity results to DTOs
    • Return DTOs to the UI

Organize DTOs by operation, for example:

  • ProductListingDTO (list views)
  • ProductAddDTO (adds)

  • ProductUpdateDTO (updates)

  • The service layer should avoid exposing ORM entities to the UI.

7) Build the DTO project

  • Create DTO classes grouped into folders/namespaces (e.g., Product/ProductListing).
  • DTOs define exactly what the UI needs:
    • Listing DTO includes selected fields (name, price, stock, category/supplier info, etc.)
    • Add/Update DTOs include only the fields needed for those actions.

8) Update the UI to use services instead of ORM

  • Remove direct ORM access from the UI.
  • UI references:
    • the service project
    • and uses DTOs from the DTO project

Typical UI workflow:

  • UI calls ProductService.ListProducts()
  • Service calls repository Select
  • Repository returns entities
  • Service maps entities → DTOs
  • DTOs bind to UI controls (e.g., DataGridView)

9) Apply the same pattern for Add/Update

  • Add:

    • UI sends ProductAddDTO
    • Service maps DTO → entity
    • Repository inserts + SaveChanges

  • Update:

    • UI sends ProductUpdateDTO containing only required update fields
    • Service maps DTO → entity or updates only the necessary fields
    • Repository runs update logic + SaveChanges

Lessons / benefits highlighted

  • Separation of concerns

    • UI does not know about ORM/database types.
    • Repositories do not know about UI formatting/needs.
    • Services handle transformation and contracts.

  • Maintainability and scalability

    • Easier extension for large projects and multi-developer work.
    • Database or UI tech changes are localized to specific layers.

  • Reusability / adaptability

    • DTO contracts make it easier to adapt/replace frontends or transport layers.
    • Example: later switching to web services is less disruptive.

Speakers or sources featured

  • Speaker/Instructor: the video’s presenter (name not provided in subtitles).
  • No other explicit speakers/specific external guests mentioned.
  • Sources/technologies referenced:
    • Microsoft Entity Framework (EF 6), NuGet, Visual Studio
    • Entity Framework Power Tools
    • concepts like WCF / web services / remoting (as possible service delivery options).

Original video