Tuesday, July 7, 2009

Dropthings - The good ideas and the bad

In a previous post I talked about my first impressions of the Dropthings project. Here I will talk about some of the ideas that I really liked in the Dropthings project, what ideas I will take away for my own project and the ideas that I thought were great but did not fit with my exact needs. And, at the very end I may add a few comments on another bad idea contained in the Dropthings project.

First I like the idea of not directly loading the widgets onto the page but instead having a common container where you load the widget, then the common container [lets call it the WidgetContainer :-)], is loaded on to the page. Here is a mockup of my version of the WidgetContainer user control:



The Dropthings project and my project save the widget information in two tables, the Widget table where all the default information about the widget is stored and the WidgetInstance table where the user specific widget information is stored. Since my requirements are that no controls are loaded until the user logs in, the entire generic user system in Dropthings, though cool, is not needed in my application.

So, after login, the process of loading the page is as simple as looping through the returned records and creating an instance of each widget inside its host container.

Lastly I would like to talk about the use of LINQ in the Dropthings project. Now I am not a huge advocate of LINQ, but there are times when it is the only tool that can solve the problem at hand, and I love it for that. What I do not like is that it:
A: Is database specific. Try running LINQ on Oracle or DB2 without purchasing third party plug-in. Sorry, cannot be done.
B: Unless it is watched very closely, the implementers of LINQ cross the data/rules boundary. In Dropthings you find LINQ commands everywhere. If you wanted to roll the Dropthings project out with an Oracle or DB2 back end, you would have a monumental time replacing all the Data access.

So, if the Dropthings project were not so tightly coupled with the data layer and workflow, I think (just my opinion) that the entire system would have benefited.

2 comments:

Unknown said...

Great analysis. The new version released this year uses the repository pattern on the data access layer. Thus all database operations are encapsulated in one layer. It uses the Repository pattern. So, you can anytime swap the default SQL Server implementation with Oracle, MySQL or even a mix of these implementations. Take a look at the latest code base.

Abhishek said...

hi omar

can u please elaborate ur saying...that the oracle implementation of dropthings is within reach...
Actually i am quite fond of your portal and looking forward to implement it in oracle....

It will a great help if u can just elaborate a little bit about the process of doing that...