0

Recently I've been working with MVC4 and have grown quite comfortable with the View > View Model > Controller > Service > Repository stack with IoC and all. I like this. It works well. However, we're moving towards company wide application platform that will serve the majority of all business applications needs within the company.

Basic architecture goals:

  • Client facing MVC site
  • Internal Admin web site
  • Plethora of scheduled jobs importing/exporting data/etc to third parties
  • Service Bus sitting in the middle to expose business events
  • Public API for customer consumption

My initial thoughts are to introduce an "enterprise service layer" by applying my service interfaces to WCF contracts and registering the WCF proxy classes in my IoC. This would allow me to reuse the same pattern I'm currently using, butt I've not found a lot of examples of this in practice. Except this guy.

Admittedly though, I'm unsure what the best solution is for a project this scale.

1) What are the considerations when centralizing business services?

2) How does this affect cross cutting concerns like validation, authorization, etc? I thought I had that figured out already, but putting DTOs between the layers changes all this.

3) I'm experienced with WCF, but I hear Service Stack is all the rage...Should SS be a consideration with its RESTful goodness?

Jeremy Smith
  • 1,349
  • 8
  • 15

2 Answers2

1

This guy here. I am not an expert in this area by any means, but hopefully I can provide a bit more context around things.

The main problem with using IoC to resolve WCF ChanelFactory dependencies as per my post is that the client also needs to have access to the service contracts. This is fine for a View > View Model > Controller > Service > Repository type architecture but is not likely to be possible (or desirable) for a shared public API.

In an attempt to cover your other questions:

1) Some of the concerns are already mentioned in your second question. Add to that things like security, discoverability, payload type (XML, JSON etc), versioning, ... The list goes on. As soon as you centralize you suddenly gain a lot more management overhead. You cannot just change a contract without understanding the consequences.

2) All the cross cutting stuff needs to be catered for in your services. You cannot trust anything that comes in from clients, especially if they are public. Clients can add some validation for themselves but you have to ensure that your services are locked down correctly.

3) WCF is an option, especially if your organisation has a lot of existing WCF. It is particularly useful in that it supports a lot of different binding types and so means you can migrate to a new architecture over time by changing the binding types of the contracts.

It is quite 'enterprisey' and has a bewildering set of features that might be overkill for what you need.

ReST is certainly popular at the moment. I have not used Service Stack but have had good results with Asp.Net Web Api. As an aside, WCF can also do ReST.

jheppinstall
  • 2,338
  • 4
  • 23
  • 27
  • RE: the public API, I actually plan to keep the business services internal and expose a separate, simplified API for customers, likely via REST that would consume our business services internally. This would eliminate their dependency on my service contracts, allow for more control of what they have access to, and allow better control over the security model on the DMZ. – Jeremy Smith May 23 '13 at 11:40
0

I've previously provided a detailed explanation of the technical and philosophical differences between ServiceStack and WCF on InfoQ. In terms of API Design, this earlier answer shows the differences between ServiceStack Message-based approach and WCF / WebApi remote method approach.

SOAP Support

ServiceStack also has Soap Support but you really shouldn't be using SOAP for greenfield web services today.

HTML, Razor, Markdown and MVC

ServiceStack also has a great HTML Story which can run on stand-alone own with Razor support as seen in razor.servicestack.net or Markdown Razor support as seen in servicestack.net/docs/.

ServiceStack also integrates well with ASP.NET MVC as seen in Social Bootstrap Api, which is also able to take advantage of ServiceStack's quality alternative components.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390
  • The cross cutting concerns are what I'm hung up about on ServiceStack. While new to SS, I've not found any great examples of how validation could be returned to different types of applications (MVC web apps, console apps, etc) without wrapping my DTOs in some transport container that holds validation details (which would bloat my responses). Could you shed some light on that topic? Also, I do see that there is support for Transactions via Redis(?) but I've no experience with it (e.g. does it flow all the way to the database?). I've only used WCF + MSMQ + DTC – Jeremy Smith May 23 '13 at 16:30
  • All exception info is serialized in the `ResponseStatus` property on the DTO, including individual validation field errors. If there are no errors the ResponseStatus is empty. You can access this error info in Razor views with the `base.ResponseStatus` and `@ModelError` properties. We actually consider the 'cross cutting' concerns of having the same service also serve as viewmodels in HTML Views a feature, so the same service can be used by web or mobile clients, etc. Ask other non-related questions in a new question. – mythz May 23 '13 at 17:39