3

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?

tereško
  • 58,060
  • 25
  • 98
  • 150
dawriter
  • 425
  • 3
  • 8
  • 21
  • Read the Microsoft architecture guide 2end edition. Its pdf and freely downloadable from msdn. Sry no link, writing from phone. – Casper Leon Nielsen Jan 08 '13 at 17:41
  • 1
    What is the reason your MVC project communicates to a WCF service instead of having a direct dependency on the business layer project? There is a lot of overhead in communicating with a web service instead of doing in-process communication. Do you really need that? – Steven Jan 08 '13 at 17:57
  • I just found it. Thanks for the heads up, Caspar. – dawriter Jan 08 '13 at 17:59
  • -Steven - we have a structure of three physical layers a Client Web Service Machine (server 1). The WCF resides on server #2 and the database resides on server #3. The WCF makes the calls to the data base on server #3 and relays them back to server #1 (the UI web page) Making calls to a database from server #1 without some middle tier in between (firewalls etc) isn't a good secure solution. – dawriter Jan 08 '13 at 18:02
  • I would urge you to reconsider Stevens question: is #1 a client browser or is it a third server tier? – Casper Leon Nielsen Jan 08 '13 at 18:47
  • #1 is a client browseer. The database resides on #3. There is no way to connect to the database from #1 to #3. One must use #2 as the WCF layer – dawriter Jan 08 '13 at 19:24

2 Answers2

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.

Casper Leon Nielsen
  • 2,528
  • 1
  • 28
  • 37
  • Caspar - this helps a lot. Forgive my confusing question. First, yes, we have a three tier approach. The first tier is the MVC 4 Project. The UI. The 2nd tier is where the WCF runs. The third tier is the database. Of course, the first and third tiers never communicate directly hence is the reason we have the 2nd tier where the WCF resides (or the web service for the .asmx users) – dawriter Jan 09 '13 at 15:17
  • For the MVC 4 projec - yes, there are "layers" and you answered my question - the dataacess layer should be a separate layer without any MVC 4 code at all. The dataaccess layer is what contains the web reference to the WCF which resides on the 2nd tier. I've succesfully physically separated the layers under one solution - one project of course. I like separating the layers as projects and I'm a huge fan of it because it makes it so much easier to spread the code around - easier to find the code as opposed to going through copious folders in ONE solution. – dawriter Jan 09 '13 at 15:20
  • @dawriter So knowing what we know now do you feel your questions have bern settled, then mark the answer as correct. If you have a followup question still mark this as answered and create a followup question. You are welcome to write me and ask for a new answer, however keep in mind that SO wants ONE question per thread. This thread is not really a good SO format thread, as its not one question and the answers are argumentative. Lets cut it down to one precise question pr thread. – Casper Leon Nielsen Jan 09 '13 at 16:52
-1

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.

neontapir
  • 4,698
  • 3
  • 37
  • 52
  • 1
    The advice not to use .net projects to enforce layer separation is worth -1. Bad, bad, bad advice. ; ) – Casper Leon Nielsen Jan 08 '13 at 17:43
  • Correct - in my case the WCF appears as a data source inside the UI but however, it should be done so separately in another layer - preferably a separate project which is rendered as a .dll of course. – dawriter Jan 08 '13 at 17:58
  • @CasperLeonNielsen, to me, choosing to use folders over projects for layer separation is a question of YAGNI. Unless you plan to deploy the layers of code of an application separately like the Distributed Deployment scenario in the MS App Architecture Guide (http://msdn.microsoft.com/en-us/library/ee658120.aspx), the code can live in a single DLL. Separating a folder into its own project file is trivial. Clearly, YMMV. – neontapir Jan 08 '13 at 23:09
  • So little comment space to pinpoint all the problems and misunderstandings contained above.. First:a rule without enforcement is just a fancy idea, "separating" in folders is just that: you think you have separated, but really its only a thought. Second: if separating a folder into an assembly is trivial, then this whole argument is moot: you should have done it initially. Third: using yagni on the principle of separation is just plain old silly. – Casper Leon Nielsen Jan 09 '13 at 07:16
  • We could of course realize that sometimes more than one logical layer can live inside one physical layer, to adhere to KISS, but that can never result in a blanket excuse, as you present above, to do this as a rule. Very small demo project, sure go ahead and represent your layers as folders. More than one developer involved? Absolutely not. – Casper Leon Nielsen Jan 09 '13 at 07:35
  • MVC4 "layers" is in my experience an exception to all this. Its easier to just maintain all three in the presentation layer, for an architectural design where the real model is represented in a layer fully separated from the presentation layer. – Casper Leon Nielsen Jan 09 '13 at 09:13
  • @CasperLeonNielsen, I'm going to agree to disagree with you on this one. I've worked with this structure before with a team of developers and did not have the discipline issues you're implying. – neontapir Jan 09 '13 at 19:49
  • @neontapir There are many valid ways to cut the cake. Some of them do not work together. My aim is not dicipline, its maintaining quality over time or keeping the cost of change at the same level in the whole development cycle (sometimes many years). We do this by ensuring (continously enforce over the whole development cycle) the architecture. You cannot enforce things that are based on loose contracts. A logical layer only represented as a folder, is not such a valid way. That being said, your point have validity in a learning situation or in a write once and deliver scenario. – Casper Leon Nielsen Jan 09 '13 at 23:07