Question

I have a project that I have recently started working on seriously but had a bit of a design discussion with a friend and I think he raised some interesting points.

The project is designed to be highly scalable and easy to maintain the business objects completely independently. Ease of scalability has forced some of the design decisions that impede the project’s initial efficiency.

The basic design is as follows.

There is a “core” that is written in ASP.NET MVC and manages all interactions JSON API and HTML web. It however doesn’t create or manage “business objects” like Posts, Contributors etc. Those are all handled in their own separate WCF web services.

The idea of the core is to be really simple leveraging individual controls that use management objects to retrieve the business data/objects from the web services. This in turn means that the core could be multithreaded and could call the controls on the page simultaneously.

Each web service will manage the relevant business object and their data in the DB. Any business specific processing will also be in here such as mapping data in the tables to useful data structures for use in the controls. The whole object will be passed to the core, and the core should only be either retrieving or setting a business object once per transaction. If multi-affecting operations are necessary in the future then I will need to make that functionality available.

Also the web services can perform their own independent caching and depending on the request and their own knowledge of their specific area (e.g. Users) could return a newly created object or a pre-created one.

After the talk with my friend I have the following questions.

1. I appreciate that WCF isn’t as fast as DLL calls or something similar. But how much overhead will there be given that the whole system is based on them?

2. Creating a thread can be expensive. Will it cost more to do this than just calling all the controls one after another?

3. Are there any other inherent pit falls that you can see with this design?

Answer 1

Do you have any other clients for the web service beyond your web site? If so, then I think that the web service isn’t really needed. A service interface is reasonable, but that doesn’t mean that it needs to be a web service. Using a web service you’ll incur the extra overhead of serialization and one more network transfer of the data. You gain, perhaps, some automatic caching capabilities for your service, but it sounds like you are planning to implement this on your own in any case. It’s hard to quantify the amount of overhead because we don’t know how complex your objects are nor how much data you intend to transfer, but I would wager that it’s not insignificant.

It it were me, I would simplify the design: go single-threaded, use an embedded service interface. Then, if performance were an issue I’d look to see where I could address the existing performance problems via caching, multiprocessing, etc. This lets the actual application drive the design, though you’d still apply good patterns and practices when the performance issue crops up. In the event that performance doesn’t become an issue, then you haven’t built a lot of complicated infrastructure — YAGNI! You are not gonna need it!