Thursday, May 20, 2010

Smart Data Transfer Object

Too often it happens when you work on distributed application that you communicate too many times to fulfill a single request. As in any network communication actual data transfer (serialization, compression, transfer over wire, decompression, deserialization, etc) is just one part and other network protocol activities also expense you nicely. You always want to minimize number of calls to the server by fetching all data that you require at once and in result better overall responsiveness.

In one of the web project, we had to present navigation tree on the left side. The tree nodes were populated based on authorization and node attributes such as Hidden, etc. Initially, when we started with implementation we simply fetched nodes using SELECT N+1 method. That was easy and simple. But as no. of nodes got increased, we started experiencing delayed response.

So then we come across
DTO pattern and using my own efficient n-level hierarchy traversal method we fetched all tree nodes at once to be sent to the client. But then this approach has contradicted with Split the initial payload guideline (its written for web UI for good for any presentation layer) and lazy loading (loading only if required).

As to solve second round of problem, we limited traversal depth level to 3. That not just reduced number of calls to server (and conforming with DTO) but also increased initial response. At max, however it is not limited, we had depth level of 5 so once the application is loaded client only had to make two more calls to reach to the node at fifth level. Well, I think that is acceptable.

To further optimize, may be we can think of expanding entire sub-tree when client explicitly ask to drill down for a given node. It just works for us and thought to share with you.


Monday, May 10, 2010

Do you buy Abstraction?

If your answer is NO, go and read below paragraph from The Gu. He answered people questioning ASP.NET MVC on the ground of abstraction. Check his complete post.

I always find it somewhat ironic when I hear people complain about programming abstractions not being good. Especially when these complaints are published via blogs – whose content is displayed using HTML, is styled with CSS, made interactive with JavaScript, transported over the wire using HTTP, and implemented on the server with apps written in higher-level languages, using object oriented garbage collected frameworks, running on top of either interpreted or JIT-compiled byte code runtimes, and which ultimately store the blog content and comments in relational databases ultimately accessed via SQL query strings. All of this running within a VM on a hosted server – with the OS within the VM partitioning memory across kernel and user mode process boundaries, scheduling work using threads, raising device events using signals, and using an abstract storage API fo disk persistence. It is worth keeping all of that in mind the next time you are reading a “ORM vs Stored Procedures” or “server controls – good/bad?” post. The more interesting debates are about what the best abstractions are for a particular problem.