2

From my understanding I though the data layer should isolate the Data Technology from the rest of the application, for me this also include the schema in this case the data entity. Recently I've been looking at the Silk project from Patterns & Practices http://silk.codeplex.com/, and noticed that data entities are translated in the business layer rather than in the data layer.

I think the advantage is that it avoid the data layer to reference an assembly containing the business model. However the fact that it expose data entities publicly is from my understanding a disadvantage because external components may be dependent of the data schema.

I would like to understand why they translate data entities in the business layer and what are the advantages?

I know that they use code first entity framework, so that the entities doesn't have data technology related dependency, however there responsibility is still to structure the data model not the business model.

Thanks

Dominik Délisle-Ong
  • 23
  • 4

2 Answers2

1

I imagine the conversion is done in the Business Layer as opposed to the Data Layer so that the Data Layer doesn't need to know every case of its use.

With the current approach it is the responsibility of the calling code to know how to use the Data Layer. If the conversion happened in the Data Layer, then it would need to be aware of all the calling code cases.

This may be pretty straight forward at first because you probably have a close to 1:1 mapping between Business Objects/Entities and the storage schema, but that won't necessarily always be the case.

Take the example of two Departments in a business working with a similar concept... let's say an Approval Workflow. Dept A calls each step in the workflow a Bla. Dept B likes that Dept A has its workflow automated and wants the same, but it calls its workflow steps BongoBlas. It is a fundamental fact of the business domain that the two workflows are identical and will always be, but the business process is such that the steps have different names (and some of the metadata fields have different names as well).

In this case you could develop a second Business Entity which uses the same persistence as the first.

If the Data Layer was responsible for conversions then it would now need to be extended to handle BongoBla conversions as well as its existing Bla conversions. This seems a bit odd because as far as the Data Layer is concerned this is none of its concern.

The Data Layer is consumer agnostic.

This is why it makes more sense for the consumers of the Data Layer to be responsible for the data conversions. When new consumers are added then only the consumer code needs to be written. The Data Layer can remain untouched. And this makes sense because the concerns of the Data Layer haven't actually changed.

Note: Sorry for the lame example scenario above. If I think of anything better I'll update the answer.

MetaFight
  • 11,549
  • 3
  • 44
  • 75
  • Hi MetaFight, thanks for your answer. I understand you're point, and it make sense to me as well. However I have some interrogations, What if I use Entity Framework in my data layer, specifically when the models reference EF. By exposing those Entities I force clients of my data layer to reference EF as well, based on my knowledge that's an issue? Also, in a team context, how can I forces clients to first translate my models? – Dominik Délisle-Ong Feb 11 '14 at 20:24
  • There are techniques for keeping your ORM details in your data layer. One of them could be adding an additional transformation layer (to DTOs). This is obviously a lot of work. What I have done in the past is use EF with POCOs. To be honest, I've heard arguments against this approach as well but haven't encountered many problems myself. – MetaFight Feb 13 '14 at 17:25
0

You can't make things totally independent and you have to make your picks. But I think what counts is to have translation on one side.

Which part could possibly change more often? Pick this part and try to depend on it as small as you can.

because external components may be dependent of the data schema

If your project data layer would be changing a lot then it is disatvantage. If data layer is more stabile then there is no problem.

Mateusz
  • 1,027
  • 8
  • 6