I am using ASP.net MVC3 for my presentation layer and my data access and business logic are exposed through a WCF Service. Should my controllers call the WCF service or should there be a further level of abstraction such as a repository which calls the WCF service.
Repository which calls the service
public ProductController(IProductRepository productRepository)
{
_productRepository = productRepository;
}
public ProductRepository(ProductServiceClient client)
{
_client = client;
}
Service directly in the controllers
public ProductController(ProductServiceClient client)
{
_client = client;
}
The repository classes do nothing apart from call the methods exposed via the service.
Sorry I am well confused about your question, but I am sorry if I have misunderstood. Hope my pointers will clear this up.
Repositories related to persistence and define a way to handle the
infrastructure layer i.e. dealing with data (in memory repository,
sql repository or generic one)
Services if you like use these repositories to perform the
contractual operations such as getting the client in your case.
Services are called by clients or someone that requests services and
service in turn calls the repository which in turn calls the data
operations.
So you may need to change your wcf to work with repositories and let your controller call services..hope that helps
I would start by doing the exact oposite - the WCF should call methods inside the repository.
The data layer should be universal, and should be able to be accessed through any means (wcf should be one, mvc website should be another, etc).
That way you can also unit test your projects, and it's easier to keep track of it. Wcf should be considered as an extra api to your program in this case.
I am more concerned of where the business rules should be stored, but I would vote for mvc controllers for business logic, and wcf services invoking those internally.
Related
We are creating a WCF infrastructure to allow other systems in the organization to consume our business logic. Some of this logic has to do with user authentication, so securing the services is of high concern. The transport layer is secured by certificates. I am more concerned with securing the business layer.
One of our clients calls these services in a certain sequence, in order to support a business process. What I would like to do is put in place some mechanism to verify that the sequence is indeed kept. The sequence can be disrupted by developer errors on the consuming side or by attackers trying to compromise the system. I do not want to put the logic of the process inside the services themselves, since this will couple them to this specific client`s process. I would like to put the logic for coordinating the different services in a separate layer, which will be client specific (or maybe something more generic to support any process?)
Can someone point me to specific patterns or resources which discuss this issue?
I have been searching Google for half a day, and I can`t seem to find any resource discussing this specific issue.
Most web services should be designed to be called independently, since there's no guarantee what order the caller will compose them.
That having been said, one way to encourage them to be called in order is to use a design akin to a Fluent Interface, in which Service A returns an object that is an input parameter to Service B.
[DataContract]
public class ServiceAResult
{
// ...
}
[DataContract]
public class ServiceBResult
{
// ...
}
[ServiceContract]
public interface IServiceA {
[OperationContract]
public ServiceAResult OperationA() {
// ...
}
}
[ServiceContract]
public interface IServiceB {
[OperationContract]
public ServiceBResult OperationB(ServiceAResult input) {
// ...
}
}
Here, the easiest way to create a ServiceAResult to pass to ServiceB.OperationB is to call ServiceA.OperationA.
I recommend you separate your concerns.
Have a web service whose operations are called in order to perform your business processes.
Have a second service which orchestrates your business processes and which calls the operations of the first service in the required order.
Do not make it the responsibility of the first service to ensure that the second service calls things in the correct order. The responsibility of the order of calls should belong to a different service.
I'm developing a server side application based on DDD.
My application service (wcf layer) has a method which received an XML from the client.
This XML needs to be processed and finally transformed into an object.
In such a case, where's the best place to put the data transformation logic?
Inside the domain model?
Example:
void OnRequestArrived(string xml)
{
ItemRequest request = ItemRequest.New(xml);
}
or in a separate domain service?
void OnRequestArrived(string xml)
{
ItemRequest request = _mappingService.Map(xml);
}
The ItemRequest object is then the main domain model for the business flow..
Thanks
This responsibility belongs to the WCF service. In DDD terms, this is the anti-corruption layer - it maps external models to the domain model at hand. The domain model should be protected from external services as much as possible.
Sometimes it can be convenient to break this single WCF service into two - an application service and a WCF-specific adapter which would adapt the application service to the WCF framework. This is based on the Hexagonal architecture. The application service knows nothing about WCF or serialization formats. The WCF adapter service handles this and other serialization concerns. This can be useful for two reasons. First it keeps your application service clean and focused on its responsibility - the orchestration of domain objects, repositories and other services to implement domain use cases. Second, it allows the same application service to be called from different adapters.
I am unsure where to place my business logic. I have a WCF service which exposes its methods to my client.
Should my business logic go in the service method
public User GetUser(int id)
{
//Retrieve the user from a repository and perform business logic
return user;
}
or should it be in a separate class where each WCF service method will in turn call the business layer methods.
public User GetUser(int id)
{
return _userLogic.GetUser(id);
}
My personal preference is to have WCF as a very thin layer on top of a separate business layer. The WCF layer does nothing more than make calls to the business layer, similar to what you have shown in option 2. This gives you some flexibility in the event that you want to have your business layer consumed by something other than WCF clients (for example, a WPF application calling your business layer directly rather than via WCF).
WCF services are already, by default, designed for reuse. I see no reason not to have some logic in your services, though keep in mind things like the Single Responsibility Principle so you don't end up with a service that does a dozen things.
Even then, if you end up parceling out your functionality into smaller classes, it's not a bad idea at all to host those classes as WCF services. You can then use them in-proc (via pipes) when needed or across machine boundaries (tcp) or even as web services. Create facades as needed to provide access to the functionality of your other, smaller services.
There's no real need to avoid putting any logic in WCF service classes.
I think that the decision depends on your business needs. WCF is a mechanism to transport data (objects) between server and client. If you like your businsess logic runs on server, you should let WCF exposes the object after running your business logic.
It should go in a separate set of classes. Your WCF layer should only contain logic that directly pertains to how the product of the service is delivered.
In your case, I see that you have a WCF method that returns a User (I assume this is a custom class) why have a separate method to return the UserID instead of populating that property as part of returning the User object?
For reuse/testability/maintenance/readability you should always put you BL in a separate layer.
I have an class library called ServiceLayer which acts as a repository for a ASP.NET MVC application This service layer has a references to a WCF Service called ProfileService which contains Profile methods to perform CRUD operations on a database etc.
I now need to allow mobile devices to communicate with my application so I have created another WCF Service called ProfileService. This service has a reference to the ServiceLayer class library and makes calls to it to undertake Profile operations.
Now this is quite confusing as I now have 2 ProfileServices. The first communicating with my database etc and exposing itself to my service layer. The second communicating with my service layer and exposing itself to mobile devices.
What is the best way to name your services in a SOA environment to avoid confusion of which type is which? especially when mapping between types.
I may also want to create another service which acts as an API to users of the system. What would I name this service ProfileAPI?? I know each ProfileService is in its own namespace but this doesnt help with readability when creating AutoMapperSettings or performing manual mapping.
So if anybody out there knows of a good way to name services in this environment it would be much appreciated.
You are looking for a Service Facade
You would end up with a Facade, which is just a specialized interface into your real service. You would define the different services as needed (mobile, users, database)
So far I found that MEF is going well with presentation layer with following benefits.
a. DI (Dependency Injection)
b. Third party extensibility (Note that all parties involved should use MEF or need wrappers)
c. Auto discovery of Parts (Extensions)
d. MEF allows tagging extensions with additional metadata which facilitates rich querying and filtering
e. Can be used to resolve Versioning issues together with “DLR and c# dynamic references” or “type embedding”
Pls correct me if I’m wrong.
I'm doing the research on whether to use MEF in Service layer with WCF. Pls share your experience using these two together and how MEF is helping you?
Thanks,
Nils
Update
Here is what my result of research so far. Thanks to Matthew for helping in it.
MEF for the Core Services - cost of changes are not justifying the benefits. Also this is big decision and may affect the service layer in good or bad way so needs lot of study. MEF V2 (Waiting for stable version) might be better in this case but little worried about using MEF V1 here.
MEF for the Function service performs - MEF might add the value but it’s very specific to the service function. We need to go deep into requirement of service to take that decision.
Study is ongoing process, so everyone please share your thoughts and experience.
I think any situation that would benefit from separation-of-concerns, would benefit from IoC. The problem you face here is how you require MEF to be used within your service. Would it be for the core service itself, or some function the service performs.
As an example, if you want to inject services into your WCF services, you could use something similar to the MEF for WCF example on CodePlex. I haven't looked too much into it, but essentially it wraps the service location via an IInstanceProvider, allowing you to customise how your service type is created. Not sure if it supports constructor injection (which would be my preference) though...?
If the WCF service component isn't where you want to use MEF, you can still take advantage of MEF for creating subsets of components used by the service. Recently for the company I work for, we've been rebuilding our Quotation process, and I've built a flexible workflow calculation model, whereby the workflow units are MEF composed parts which can be plugged in where needed. The important part here would be managing how your CompositionContainer is used in relation to the lifetime of your WCF service (e.g. Singleton behaviour, etc.). This is quite important if you decide to create a new container each time (container creation is quite cheap, whereas catalog creation can be expensive).
Hope that helps.
I'm working on a solution where the MEF parts that I want to use across WCF calls are stored in a singleton at the application level. This is all hosted in IIS. The services are decorated to be compatible with asp.net.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
In Global.asax, I import the parts.
[ImportMany(typeof(IOption))]
public IEnumerable<IOption> AvailableOptions{ get; set; }
After initializing the catalog and container, I copy the imported objects to my singleton class.
container.ComposeParts(this);
foreach (var option in AvailableOptions)
OptionRegistry.AddOption(option);
EDIT:
My registry class:
public static class OptionRegistry
{
private static List<IOption> _availableOptions= new List<IOption>();
public static void AddOption(IOption option)
{
if(!_availableOptions.Contains(option))
_availableOptions.Add(option);
}
public static List<IOption> GetOptions()
{
return _availableOptions;
}
}
This works but I want to make it thread safe so I'll post that version once it's done.
Thread-safe Registry:
public sealed class OptionRegistry
{
private List<IOptionDescription> _availableOptions;
static readonly OptionRegistry _instance = new OptionRegistry();
public static OptionRegistry Instance
{
get { return _instance; }
}
private OptionRegistry()
{
_availableOptions = new List<IOptionDescription>();
}
public void AddOption(IOptionDescription option)
{
lock(_availableOptions)
{
if(!_availableOptions.Contains(option))
_availableOptions.Add(option);
}
}
public List<IOptionDescription> GetOptions()
{
return _availableOptions;
}
}
A little while ago i was wondering how I could create a WCF web service that will get all of its dependencies wired by MEF but that i wouldnt need to write a single line of that wire up code inside my service class.
I also wanted it to be completely configuration based so i could just take my generic solution to the next project without having to make code changes.
Another requirement i had was that i should be able to unit-test the service and mock out its different dependencies in an easy way.
I came up with a solution that ive blogged about here: Unit Testing, WCF and MEF
Hopefully will help people trying to do the same thing.