CODEWITHSUNDEEP
c#wcfdatasetdomain-driven-design
mbue
mbue

Reputation: 1632

WCF Service and large data tables - any alternatives to ddd/business objects?

Normally, I try to focus paradigms like DDD do have a clean application architecture, salted with ORM, IoC and so on. Now I need to set up a WCF service which delivers complete data tables (with ALOT of columns) but has rarely any business logic / algorithms. The data comes from CRM applications which just needs to be transfered via a common endpoint (the WCF service).

Applying DDD or other domain/business object related designs ends up with writing alot of boillerplate code, ORM xml configurations and infrastructure code which seem just too oversized for those somewhat primitive requirements.

The best would be to have some DataTable/DataSet approach, but it seems like using them with WCF is an anti-pattern and considered as bad design.

So what are the alternatives? Maybe some reflection-based XML serialization? Are there any common patterns?

edit: The data from the CRM is written into a SQL server database which I have to read before transfering the data. The schema changes pretty often (new columns are added) but I don't have to care about the structure as I just need to transfer the data to somewhere else. That's why I liked the idea of populating DataSet/DataTables

Thank you in advance.

Upvotes: 0

Views: 347

Answers (1)

MaxSC
MaxSC

Reputation: 4758

You’re right saying that setting up all this just for a WCF service is just too oversized.

DDD is useful when you want to design a business application, when you need to model the domain you’re dealing with. In your case, the business app seems to be the CRM, not the WCF service.

I guess that you’re retrieving data from your CRM application via an API.

What I would do first is to design all the DTO’s the WCF service will transfer and define the WCF service contract. By designing first your contract and DTO’s would allow the consumer to integrate it into his application and see if it fits the requirements.

You might end up transferring huge object graphs, but it’s better than trying to transfer DataTables. What I would do as well, is to encapsulate the response object graph into a methodName+Response object (and if needed, the request object into a methodName+Request object) for readability purpose.

As soon as your DTO’s and service contract have been designed, all you need to do is just to call your CRM API, get data and then map them to your DTO’s.

Be sure to properly separate things in your .sln, here’s how I used to do when dealing with WCF services:

enter image description here

.WCF: the web project that will be deployed, it only contains the .svc file and the .config file.

.Interface: Where I put all the DTO’s and service contracts.

.Implementation: The service implementation (where you’ll call your CRM API)

.Mapping: The DTO <> CRM data mapping classes

This way, everything is correctly separated.

Hope that helps!

Upvotes: 1

Related Questions