Engineering Handbook

Service Standards and Naming Conventions

Make sure to read the Handbook Extension: Services.

Services (Services always end with xxx.Service)

Always use a solutions folder if it does not already exist. All Services are suffixed with dotService in order to make finding the actual DLL easy within a solution.

Structure

• Layered Architecture. Click here to view or update this structure in Miro.
• Our policy is each service does one thing and one thing well.
• The service business logic will not be repeated. Even though the Core project is available across services.
• All services will return a DTO and never an entity. The entity itself is shielded from the controller. A DBcontext cannot be initialized from the Business layer.
• Use caching in instances where common data is queried and does not change much.
• Use relationships so that you limit DB connections.

Caching

• In-Memory Cache in dotNet:
  1. Caching can be done using inline caching or cache action filters. Example of these can be found in the Globalntegration > Helpers > Filters Folder
• For Angular caching, read this related article on ShareReplay.
• Please take precaution when using caching. Refresh/Delete the cache when data changes etc.

Service Solutions contains the following projects

• Solution.Service.API

  Controllers

• Solution.Service.Business

  Business Logic related to this project
  Includes Integration Folder for external service calls (Preferred method: Fluently)

• Solution.Service.Data

  DbContext Model Enitities Unit of Work

• Solution.Service.Dto

  Classes correcponding to enities in Model Enitities

• Solution.Service.UnitTests

  Create unit tests per model entity

General

• Always prefer meaningful names for your class, property, method, etc. This will be very useful for you to maintain the code in future.
• Never have a different class or variable name that is in a different case.

  Example: Entity and entity.

• Don’t use the same name used in .NET Framework. Developers who are new to your code have great difficulty to understand it easily.
• Always use “I” as prefix for Interfaces. This is a common practice for declaring interfaces.

  Example: IEntity.cs

• Never prefix or suffix the class name to its property names. It will unnecessarily increase the property name. If “Firstname” is a property of Entity class, you can easily identify it from that class directly. No need to write EntityFirstname or FirstnameOfEntity.
• The prefix “Is”, “Has” or “Can” for boolean properties like these give proper meaning to the properties.

  Example:

  IsVisible
  HasChildren
  CanExecute
  

• Private variables start with an underscore.

  Example: private bool _IsVisible;

• Paramenters must be descriptive (do not use: int value) and start with lowercase then pascalCase.

  Example: (int entityNumber)

• Methods give descriptive names as simple as possible. Starts with capital letter, then pascalCase.

  Example: GetEntity(int entityNumber)

• When a method has a return value that will not be used, use discards, this enhance its readability and maintainability. Discards - C# Fundamentals
• Always use curley brackets {} for if, switch, for, etc statements, even if it has only one line of code.