CODEWITHSUNDEEP
c#wcfarchitecture
Learner
Learner

Reputation: 3416

wcf architecture - how to design my service contract in a flexible way

I have some entities like: Customers, Orders, Invoices.

For each one of them I grouped their CRUD operations and few other in interfaces like: ISvcCustomerMgmt, ISvcOrderMgmt, ISvcInvoicesMgmt, ISvcPaymentsMgmt.

Now I need to create few WCF service contracts independent to each other which will consist of implementing one or more of this interfaces.

  1. one for internal use ISvcInternal: ISvcCustomerMgmt, ISvcOrderMgmt, ISvcInvoicesMgmt //,maybe more in the future
  2. one for external use (3rd parties) ISvcExternal: ISvcCustomerMgmt //,maybe more in the future

So, my real services look like this: 1) SvcInternal: ISvcInternal, 2) SvcExternal: ISvcExternal.

When I see SvcInternal implementation, it gets bigger with a lot of operations.

Is this method flexible enough? Do you recommend another approach of splitting them up somehow? Feel free to share your thoughts.

Thank you.

Upvotes: 4

Views: 1276

Answers (3)

R.G. Faber
R.G. Faber

Reputation: 11

At our company, services consist of 3 assemblies:

1) the "contract" assembly which we name [Company].[Project].Contract. This assembly contains the DTO (Domain) objects, the Interface definitions and a Client class to access the service. This assembly can be shared with those who want to consume your service.

2) the "business" assembly which we name [Company].[Project].Business. This assembly exposes a factory class that returns interfaces to the internal business worker classes.

3) the "service" assembly, which we name [Company].[Project].Service for a traditional SOAP service or [Company].[Project].Rest in case of a REST service, it is the "facade" that publishes the service's interfaces and covers the transport and protocol logic.

Putting all functionality in one service is a good option to start with, but you will soon find that certain classes belong together naturally, so you will probably end up with a number of domain specific services.

Now, WCF has this great concept of configuration, but those who have field experience with this will agree that this can be very tedious and error-prone, especially when your SOA becomes more complex (as it always does, eventually). This always results in very complex configurations, multiplied by the various environments (development, test, staging, production) the services will run in. Needless to say this might result in errors.

To cope with this, we use the broobu framework that allows near-zero config for WCF services using WS-Discovery and dynamic proxy generation the only drawback for this solution is that you preferably use IIS-hosted services with AppFabric 1.1. This way, you use IIS to configure the services: much safer (since you won't use XML config files) and much more scalable.

Upvotes: 1

Roy Dictus
Roy Dictus

Reputation: 33149

This can be an endless debate... How you choose to group your service operations is up to you.

One way is to put everything in a single, cover-it-all service, which acts as a façade to cover the internal complexities. But, as you say, that can grow quickly.

Another option is to have one service per entity type, or per aggregate root. An aggregate root is an entity that has an ID and is independently manageable from other entities. An example: you may have an Invoice entity and an InvoiceLine entity; then the Invoice entity is an aggregate root but the InvoiceLine entity is not, because it cannot exist without an Invoice -- therefore, it is not independent.

Yet another approach is to divide up per domain -- that is, divide up the service into smaller services that are each consistent and independent of the other services. Sometimes that is possible, sometimes it isn't. Use your judgment.

Upvotes: 2

Usman Masood
Usman Masood

Reputation: 1977

if i have to implement this i would say i will put all the code and Operations in a Worker Manager or Fascade Layer... that will consist of all operations... (Real coding logic).

my service will be only a thin client that will only pass request to Fascade layer.... This allows me to reuse a great amount of code... and it also allows me to expose same method in more then one services without ReImplementation.... One point though why don't you use differentiate b/w you internal and external services with different bindings... e.g. even if you are going to use WSHttpBinding or BasicHttpBinding for both services create different endpoints and binding for them....

in terms of Code Hirerachy my idea would be of using folder hirerachy and namespaces to differentiate b/w this... e.g. Namespace.Interfaces.Internal and vice versa...

hope that helps.

Upvotes: 3

Related Questions