Cline Rules

Cline Rules

Global Project Rules for ErpCrystal_MFG

This document outlines the global rules and conventions for the ErpCrystal_MFG project, covering project structure, C# coding standards, API development, and data access. Adhering to these guidelines ensures consistency, maintainability, and scalability across the codebase.

1. Project Structure and Naming Conventions

  • Project Naming: The root project is ErpCrystal_MFG. Sub-projects should follow the pattern ErpCrystal_MFG.Layer (e.g., ErpCrystal_MFG.Api, ErpCrystal_MFG.Models, ErpCrystal_MFG.Web).
  • Namespace Naming: Namespaces should reflect the project and logical layer, following ProjectName.Layer.SubLayer (e.g., ErpCrystal_MFG.Api.Controllers, ErpCrystal_MFG.Api.Repositories, ErpCrystal_MFG.Models).
  • Folder Structure: The folder structure should mirror the namespaces and provide a clear separation of concerns (e.g., Controllers, Repositories, Context, Models).
  • File Naming: C# class files should be named [ClassName].cs.

2. C# Coding Standards

  • Naming Conventions:
    • Classes, Interfaces, Methods, Properties: Use PascalCase (e.g., SalesDashboardController, IDashboardRepository, SalesDashboardData, Prompt).
    • Local Variables, Parameters: Use camelCase (e.g., idashboardrepository, dbname, prompt).
    • Private Readonly Fields: Use _PascalCase (e.g., _IDashboardRepository, _DapperContext).
  • Access Modifiers: Explicitly define access modifiers (e.g., public, private readonly).
  • Asynchronous Programming: Utilize async and await for all I/O-bound operations, returning Task or Task<T>.
  • Dependency Injection: Prefer constructor injection for services and repositories to manage dependencies.
  • Data Transfer Objects (DTOs): Use simple Plain Old CLR Objects (POCOs) for data transfer between different layers of the application.
  • String Initialization: Initialize string properties with string.Empty instead of null to prevent NullReferenceException errors.
  • GUIDs: Use Guid.NewGuid().ToString() for generating unique identifiers where appropriate.
  • Data Annotations: Apply System.ComponentModel.DataAnnotations for basic model validation.

3. API Specific Rules (ErpCrystal_MFG.Api)

  • Routing: Implement consistent API endpoint URLs using [Route("api/[controller]/[action]")].
  • API Controllers: All API controllers should inherit from ControllerBase and be decorated with [ApiController].
  • Authorization: Implement custom authorization attributes, such as [ApiKeyAuth], when security measures are required.
  • Return Types: API actions should return IActionResult to allow for flexible HTTP responses.

4. Data Access Specific Rules (ErpCrystal_MFG.Api.Repositories)

  • Data Access Layer: Use Dapper for efficient and lightweight database operations.
  • SQL Queries: Embed SQL queries as strings within repository methods. Always parameterize queries to prevent SQL injection vulnerabilities.
  • Connection Management: Utilize DapperContext to manage database connections, ensuring proper distinction between client-specific and system connections.
  • Repository Pattern: Define interfaces for all repositories (e.g., IDashboardRepository) and provide concrete implementations in separate classes.

5. Flow For Any Method

  • If Required in Razor Pages then it should be start from razor page > then IService > Service > Controller > Irepo > repo
  • If required in Controller only then Irepo > repo

6. Temp Table and New table create script Rules

  • Always take Id column id INT PRIMARY KEY IDENTITY(1,1)

Other Important Rules

  • Never add any new code in between old call , add at the end of the file