Please enable JavaScript.
Coggle requires JavaScript to display documents.
ASP.Net MVC Full stack development v4 (Refactoring Towards Clean…
ASP.Net MVC Full stack development v4
Modularizing JavaScript Code
Refactoring Towards
Clean Architecture
Extract methods from code where possible
Use repository pattern
Decouples from persistence frameworks - npr. Entity Framework
Provides better separation of concerns - Controller is no longer responsible for querying
Minimizes duplicate query logic
Use for complex queries to get rid of fat controllers and far services
One repository per domain object - GigRepo, UserRepo
Repository
is lke a Collection of domain objects in memory and
it's public methods shoudn't change the database state (eg. save changes)
Unit Of Work Pattern
Responsible for saving DB changes (eg.dbContext.SaveChanges)
Consolidating Repositories dependcies - moving repo
dependencies from the controller (Bussines layer is no longer dependent of the data layer)
Programming against interfaces
Dependency Inversion principle
2 principles
High level modules should not depend on low level modules (eg. Controller on UnitOrWork - if UnitOfWork changes Controller needs to be recompiled and changed)
Low level module can easily be replaced - eg. EF with newer version of EF or another ORM
Both should depend on apstractions (interfaces) - if one changes the other wont be affected as long as the contract (interface) stays the same
Abstractions(interfaces) should not depend on details(concrete classes) - Details should depend on abstractions
Interface shoud not implement concrete types, only abstract
Dependency injection DI
Class has no dependency to concrete types, only to abstract (interfaces)
Injecting dependecies into the class via it's constructor
DI frameworks - they initialize concrete objects based on configuration and pass them as dependecies into diferrent classes
StructureMap
AutoFac
Ninject
Unity
Restructuring Application - when the code becomes or it will become to complex
Persistence package - Persistence framework logic
(EF, LinqToEntities...)
includes persistence code (e.g. EF queries (Repository classes, EF migrations...)
Core package - All abstractions
Decouples Controllers from Persistence
Ignorant and not dependant about any persistence or presentation frameworks
UnitOfWork and Repository Inerfaces, Entities, Dtos, ViewModels
It takes more time but it's pays off in the future
You know exactly where to put each method, class...
Package have engineered to have minimal dependencyes on each other - future changes will be better isolated
Refactoring Data Annotations (DA)
If the domain classes are polluted with DA used by EF
DA have limitations - you can not configure relationships with them
Refactor using fluent API
Introduce configuration classes derived from EntityTypeConfiguration<> for each entity