We are using Entity Framework with SqlServer Database. Business program needs to create many columns which are not in the Database, due to storage, high querying cost etc. Currently, the team is Copying the whole DB Entity Layer (from scaffolding), and Creating whole another layer adding computed members in new entities. Currently taking EF layer and applying AutoMapper to new layer. For some reason, not sure if this is optimal, however architect wants it this way.
Is it general practice in Software industry to copy the Database layer into another Copy layer with Computed Members? I'm aware of DDD Domain Driven Design, however we are not creating Aggregate Roots, Value Objects, Clusters, etc.
What is an alternate solution if this is not good practice?
*I started software programming two years ago from college, curious if this is good industry practice, or alternative exists. Searched all over google and stack, and did not cite this strategy.
SQL Database ---> EF Layer ---> Another Copy Layer (with EF and computer members in the class) ---> Application Service ---> Dto ---> Controller APIs
I agree with every layer, excepted this EF copy layer with computed members. Couldn't we just utilize partial classes?
Example: New class layer would contain all existing members, plus these added in a class, etc.
FullName => FirstName + LastName AccountValue => Quantity * StockPrice
Would like to hear from people who think differently also, appreciate answers below,