MVC 4 - 在数据层中消耗WCF

Question

In my test project, I created a WCF service and got it running. Next, I created an MVC 4 project. It is broken into layers under one solution.

• The model layer.
• The UI/View/Controller layer
• The repository layer.

To do a quick test: In the UI layer, I added a web reference to my WCF service. In the controller, I contacted the WCF service by "using" to populate a dropdown in the view.

However, I'm driving for separation with Dependency Injection.

In the repository layer, I created an Interface with the populate dropdown and injected it. Not a problem.

What I'm struggling with the concept is:

1. Do I consume the WCF service in the UI layer and reference it in the repository layer? (doesn't seem right)
2. Do I create another project - a data layer - and add a web reference to the WCF service then from the repository, I create a reference to the data layer?

Which brings me to another question - if I create a web reference to a WCF service in a separate project (layer), the information pertaining to the WCF service is not present in the main config.sys file...

So I'm struggling to grasp this portion...anything I should be reading up on some more?

Answer 1

Realizing that your cake can be cut in many ways, I present you here with my take on how to cut it:

Question #1: "Do I consume the WCF service in the UI layer and reference it in the repository layer?" First off: As Steven points to in your comment, you should consider deeply if you want to inject a third server tier. The UI layer can be renamed to the "layer that is hosted in IIS". Doing so makes it the host layer for both your MVC presentation layer and the host layer for the services. However this does not mean that your services are implemented in this layer, only that they are hosted here (a matter of referencing the interfaces and implementation namespaces in the web.config only).

Question #2: "Do I create another project - a data layer - and add a web reference to the WCF service then from the repository, I create a reference to the data layer?" As I read this you are asking multiple questions at once: Yes, you should create a separate layer to encapsulate the repository. No you should not let this layer contain anything related to wcf. If a server layer needs client access to a wcf service, you should separate this into a logical layer, either residing as a folder in your businesslogic layer, or as a separate physical "data adapter layer". Never ever in your repository layer. While it is true that conceptually the wcf data adapter layer is at the same level as your repository layer, you should not mix database access and service access in the same logical or physical layer.

The third question I can only answer as a question: What purpose is it that you want WCF to fullfil in your architecture? Do you want to inject a separate service tier or have you confused layer separation with tier separation?

Layer separation can be coupled runtime in-process, while tier separation can only be coupled runtime through some sort of on-the-network remoting (such as wcf).

As Steven points out in his comment, you havnt really documented the need to use wcf in your architecture at all.

Lets look at your architecture in terms of the logical layers and tiers (cutting the cake):

• Client-Access-Layer (#1, running in the context of the browser)

• Web-Host-Layer (#2, representing the outer server tier, contains all MVC code. Perhaps Model exists in its own physical layer.

• Service-Layer (Not existing yet in your architecture, as there have been no need demonstrated for this further abstraction of layers into tiers)

• Business-Layer (#2, representing the business logic that lies between presentation and database and data access layers)

• Repository layer (#2, encapsulating database access logic and mapping)

• Service Access layer (#2, encapsulating access to services on the outside, can be implemented as a folder in BL layer or in a separate physical layer)

• Database tier (#3, the sql server)

So are you asking how to implement DI in WCF using IIS as the host and C# as the implementation language.

Or.

Are you asking general guidance into architecturing a n-tier .net application.

The first is easy, as there a tons of examples out there, such as this

The second is more tricky as the answer will always be "it depends". It depends on what your needs are, what your level of expertise is, what the projected timespan of your project is and so on.

Hope this helps you a bit.

If you want I can send you my implementation of the behavior wcf unity stuff.

Concepts:

• Logical layer - an architectural concept used to isolate responsibility. Layers have downward coupling, never upwards.

• Physical layer - an implementation construct used to enforce the logical separation. A .net assembly can be used as the implementation of a physical layer.

• Tier - one or more layers that can exist on a machine that is not hosting other tiers.

Answer 2

It sounds to me like you're treating the WCF call as a data source, which makes it a natural fit for the repository layer. The repository's job is to abstract knowledge of the data source's implementation from the other layers.

I would recommend not using .NET projects to enforce layer boundaries but rather to use folders within the same project to enforce logical separation rather than physical separation. Most use cases don't require physical separation and it adds complexity, such as the more difficult configuration you noted.