Refactoring multiplicity, synchronous versus asynchonous

18 Dec 2010

Sometimes change hurts.

You know what I’m talking about if you need to change the multiplicity of a relationship (let’s assume you talk about an ordinary sql database). For instance: From 1 to 1 To 1 to many For instance, say it’s an address. The assumptions made when there is only one address permeates throughout the applications. For instance a person must have bills sent to a different address (his/her accountant or something similar). However, when contacted, any mail needs to be sent to the home address. The code changes alone could be many. If there are a lot of reports based on the data (accessing the information without any layer) then these could be based on assumptions out of sync with reality. If you’re unlucky that might mean that you need to manually go through all the reports in the system and look for discrepancies. If you’re lucky the report will simply fail. If unlucky, it will show a random address.

Synchronous versus asynchronous execution and parallel execution jQuery has popularized asynchronous programming. Reactive extensions will perhaps simplify your tasks. Parallel LINQ (PLINQ) and the Task Parallel Library (TPL) might even make the tasks even simpler. But what if your program assumes execution in a consecutive manner? That the parts that you need to make parallel or asynchronous are buried deep within layers of layers … It might be that your program design needs to be restructured.



Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.

Do you want to fix an error or add a comment published on the blog? You can do a fork of this post and do a pull request on github.