Should we use a WCF service as our service layer facade in nTier application

2
votes

So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.

We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.

I was thinking something like the following:

  • Core - domain objects (poco's)
  • Data - Entity Framework (Code First) or nHibernate exposed as Repositories
  • Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
  • UI (MVC) - Controllers and Views.

This would all be tied together using a DI container such as Autofac.

We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.

So - does the above sound like a good overall architectural pattern for a pretty standard business application?

The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.

My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.

What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?

OR

Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?

Any thoughts would be really helpful as I don't know what best route would be.

2
asp.net-mvc-3design-patternsarchitecturewcf-data-servicesn-tier-architecture

2 Answers

2
votes

Should we use a WCF service as our service layer facade in nTier application

Depends on if any other application than the MVC application is going to talk to the service.

  • MVC3 is the only app: You aint gonno need it
  • Other apps too: Sure. Do it.

What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming

Don't use the concrete service classes. Use the service interfaces. Problem solved.

My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API

I hope that you mean the same WCF service.

Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?

ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.

1
votes

Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).

In your mvc application you can consume the service by endpoint url.

Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.

Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))