2

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,

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.

| improve this answer | |
  • why not just utilize partial classes? – Artportraitdesign1 Jan 6 at 9:28
  • @Artportraitdesign1: Partial classes make no difference here. They are essentially the same as having one class which contains the same content that you would've spread across those partial classes. There is no meaningful difference with (nor reason to use) partial classes in your scenario. – Flater Jan 6 at 9:31
  • well I thought about using partial classes, just to eliminiate the need for another layer with computed columns, ok well thanks – Artportraitdesign1 Jan 6 at 9:31
  • by the way, could I just create a console program which will copy all the files into another project for this new layer everytime we rescaffold? I was considering doing this, and then writing partial classes on top of this new layer – Artportraitdesign1 Jan 6 at 9:33
  • 1
    @Artportraitdesign1: Can it be done? Sure. But it misses the point that one day this copy might no longer be an exact copy, at which point your copy process is unusable. If that day never comes, then the abstraction was somewhat unnecessary (but that still doesn't mean you should've gambled on this by not making the abstraction - caution has value even if things don't go wrong). – Flater Jan 6 at 9:47
0

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

| improve this answer | |
  • 1
    why not just utilize partial classes? thanks – Artportraitdesign1 Jan 6 at 9:28
  • 1
    Even when using code first on domain objects (with no attributes etc), it's still better to separate the db entity from the domain object. A domain object can exist of more than just its db entity (e.g. if certain information is retrieved from another data source). Entities and domain objects do not have the same functional purpose and conflating them will lead to an unpleasant exercise in having to separate them at a later stage. – Flater Jan 6 at 9:29
  • partial classes are just single classes in two files. They dont solve anything – Ewan Jan 6 at 9:29
  • @Flater there is no such thing as a "DB Entity" – Ewan Jan 6 at 9:30
  • by the way, could I just create a console program which will copy all the files into another project for another? I was considering doing this, and then writing partial classes on top of this new layer – Artportraitdesign1 Jan 6 at 9:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.