CODEWITHSUNDEEP
c#.netwcfooptypes
Andrew
Andrew

Reputation: 59

Passing a Type through Layers

I have three layers in a solution: Data Access (DA), Business Logic (BL), and WCF Contract Logic (CL) - in stacked in that order of course.

In the DA is stored an Entity Framework model with a SQL table in the form of a type. I want to access this type up the layer stack in the CL, but I don't want to commit bad pratice and have the CL talk to the DA directly, but rather CL to the BL and BL to the DA - if that makes sense.

Simpliest way forward is merge the BL and CL layers, but supposing I want to keep the specified seperation in my solution, how could I achieve what I have stated previously?

I have thought about the following solution:

  1. Inherit the type from the DA into the BL to create a a new type.
  2. Create a new Interface in the CL as manual template of the new type in BL.
  3. Create a new Type in CL using an Interface.

Problem with the above solution is, if an update happens to the type in the DL, the interface in the CL no longer is true and could break the application. I would like a solution that auto updates all layers without manual intervention.

Rough diagram

Any awesome suggestions?

Upvotes: 1

Views: 92

Answers (3)

Paul51
Paul51

Reputation: 39

Don't implement any of the 3 options you detail. As the guys above have indicated a Common Assembly that contains the DTO's or Pocos and maybe the Interface contracts that will be used by all the layers.

I would advise to use the DTO's or Pocos in the interfaces between layers and for shuttling data around. A good doc with good examples https://learn.microsoft.com/en-us/aspnet/web-api/overview/data/using-web-api-with-entity-framework/part-5

Upvotes: 1

Jon Lopez Garcia
Jon Lopez Garcia

Reputation: 237

Three tier layer + dto

You'll need to implement a fourth layer who will be referenced in all the others layers (eg: Common Layer). You'll define in it the types that you'll use across your application.

Here is a good article explaining the different approaches you can use.

Upvotes: 1

Akos Nagy
Akos Nagy

Reputation: 4359

A solution could be to have a fourth layer: a Model layer. This model contains all the classes that you would like to use as POCO classes. Since they are POCO classes, they are not dependent on EF. You can decorate them with DataMember and DataContract if you want. It's not the nicest solution, but I don't think this breaks the abstraction or leaks it, if you think of DataContract as an alternative for Serializable (of course you could take this to the next level and write serialization surrogates, but that's quite a lot of work). Note that the model does not depend on WCF either way, because these types are in the System.Runtime.Serialization assembly, and not the ServiceModel assembly (and of course, no dependency on EF either).

Reference the Model from the DAL. In the DAL you can create your EF DbContext (disable lazy loading and proxy generation), add the EntityTypeConfigurations with the fluent API, and so on.

And then go ahead and reference them from the BLL and from your contract layer as well.

This way you have a single, unified model layer with POCO classes, and besides the questionable serialization attributes, it's technology-agnostic.

Upvotes: 1

Related Questions