Copy Database Entities into Another Layer in Software Architecture?

Question

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.

So basically

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

Update:

Would like to hear from people who think differently also, appreciate answers below,

Answer 1

Is it general practice in Software industry to copy the Database layer into another Copy layer with Computed Members?

Example: New class layer would contain all existing members, plus these added in a class, etc.

FullName => FirstName + LastName
AccountValue => Quantity * StockPrice

What you're seeing used here is the distinction between the entity (= the database record) and the domain object (= the "fuller" data object). This is not unique to DDD. DDD does emphasize it more strongly than other approaches, but it's a perfectly viable approach even in non-DDD scenarios.

Where would you put your computed values? You shouldn't store them in the database (unnecessary data size bloat), and you want these computed values to be readily accessible by all consumers of your domain. Logically, the domain must then wrap this around the db record, which is the "copy layer" you're referring to.

---

Referring to it as a "copy layer" suggests to me that you don't see the purpose of abstraction layers.

This layer is not a copy, it is a separate layer with its own functional purpose (one of which is to abstract away the database entities from the domain). It just happens to partially resemble the database entities because it exposes similar data (among other things).

That is not to say I don't see where your interpretation comes from. It often feels unnecessary to write something that effectively duplicates another layer. While this additional abstraction may not be necessary today (if it completely resembles the database layer), it's much easier to implement from the beginning than it is to have to retroactively add it in at a later stage when it does become necessary.

In that sense, it is necessary to implement this abstraction layer today, in order to avoid a more cumbersome task tomorrow.

Answer 2

Yes this is common practice.

It seems weird with EF because EF makes objects for you. If you were just using SqlClient with DataReaders and the like directly you wouldnt think twice.

The problem is the EF objects are often tightly coupled to EF via attributes. This means wherever you use the Object you have to reference EF. Which you don't really want to do when you are not using it.

In theory you could do code first EF objects and use the Business Layer objects directly, but in practice its sometimes easier just to map the EF objects to a Business Layer via the repository pattern