My Key Principles
OOP
Because I use .NET, I always strive to implement object-oriented code with all its benefits.
Solution structure
I’m very careful with the whole solution structure: I always strive to follow REP (Reuse/Release Equivalence Principle), CCP (Common Closure Principle) and CRP (Common Reuse Principle) principles and find the optimal partitioning into assemblies. If a part of the code needs some specific dependency (e.g. the library for sending email) – I always move it to a separate project in such a way that code which works only with the database (for example) will not pull in this unnecessary dependency. I’m very careful with cyclic relationships and will refactor code to avoid them (ADP: Acyclic Dependencies Principle). I feel happy when I see a strong tree-view dependency structure of the solution and won’t rest until I refactor it to resolve all dependency problems.
Dev Practices
I try to follow SOLID / GRASP / KISS / YAGNI principles, and I will refactor code until I’m happy with it
External libraries
I try to avoid unknown heavyweight third-party libraries (NuGet packages) with many dependencies to solve one small task and will seek an alternative solution. I keep all NuGet packages updated to the latest version and ensure control to avoid conflicts among them.
Solution Layers
I am a supporter of using “as small and lightweight models as possible”, I prefer to create one more suite of DTO classes (anemic models) to transfer data between layers instead of using the same class for several layers.
Database layer
All “database” classes, database logic, stored procedures etc are always in separate project within the solution. Entity Framework with db context is added as NuGet package only there and nowhere else. Frontend project is as lightweight as possible with minimum logic, containing only logic related to the frontend and no business logic. All specific packages are always in their own separated projects.
Database design
I always strive to achieve 4NF (Fourth Normal Form) for relational databases if business logic conditions do not require any exceptions (OLAP-processing)
Object naming convention
I prefer to see consistent object naming (variables, classes, etc.) throughout the entire solution.
No hardcoded strings!
All configuration things are exclusively in config files. Static data (such as static strings) can be in separate constants in special classes. No potentially changing constants in business logic, no hardcoded strings
Abstractions
Working with interfaces, not with concrete classes (if they have base behavior – use abstract class). Use dependency injection instead of using concrete classes directly. Interfaces and their implementations are in separate projects within the solution.
Web API
WebAPI controllers always have only call of methods from services and don’t have business logic. I always try to follow RESTful rules (even HATEOAS level if necessary), every action has appropriate response status code and appropriate VERB, every possible exception should be caught (locally or on global level) with appropriate response to client. I prefer to use handlers and filters to catch exceptions and other cases rather than writing handler’s code directly to controller’s method
Unit Testing
Covering critical and complex logic with unit tests (I’m not a supporter of covering all code with unit tests. I think it’s waste of time and adds additional difficulties, acting as a barrier to code changes and making the solution less flexible). However, covering base things with unit tests not only helps to identity unexpected behavior and results of methods during development stage but also keep solution structure clear with correct dependencies.
