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
Entity Translation Should be in the Data Layer or Business Layer
design;translate
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.