Wednesday, January 6, 2010

Advantages of Jquery

Since past 6months, I am using jquery and its plug-ins, posting this.

* its light weight when compared to other javascript frameworks
* it has a wide range of plugins available for various specific needs
* it is easier for a designer to learn javascript as it uses familiar CSS syntax. jQuery is Javascript for Designers
* Large development community and many plugins.
* It's on Microsoft's radar and they are adding some plugin support and debug capabilities.
* Very good documentation for a 3rd party library.
* Chaining capabilities are very powerful.
* The online documentation is fantastic.
* Performance seems to be very good as well.
* The entire library fits into a relatively small package given it's capabilities.
* The plugin architecture is also very nice for extensibility. 1.
* It's very small, especially when minified, and offers a lot in the core library.
* It's also easy to extend, and has an active community.
* Finally, it's extremely easy to learn; once you've grasped the core concepts you can start coding complex solutions right away.

Monday, January 4, 2010

Did you know… How to - - in Visual Studio tips

http://blogs.msdn.com/saraford/archive/2008/12.aspx

Sara Ford gives the daily tips to use the VisualStudio efficiently.

Raw data access vs ORM

The "fastest" way to do data operations is with a Sql Connection working with a sproc (assuming the sprocs are efficient). Period. Using an ORM like Linq to Sql, Entity Framework, nHib will not make your code run faster. Furthermore, if not done properly, there may be many db calls for a single task - something which would not be an issue with "normal" data access.

Does that mean ORMs are useless? Definitely not. As you said, creating a custom data layer would require a lot of extra coding. And ideally, that would mean a lot of testing. And not just simple unit testing, the number of integration tests should increase too. There's a productivity issue to consider here.

ORMs - when used properly - can maintain a decent performance level (although slower than raw data access) while at the same time promote some patterns that means the overall quality of code would increase. It could promote consistency and easier testability. You could, for example, keep your data access in a repository and the business code in a service layer. That would mean you could unit test your service layer and need integration tests for the data layer. Granted, something like this could definitely be done without an ORM - but it's far easier using an ORM.

ORMs are slower than raw data access, yet they contribute to manageability and testability. I use ORMs extensively and if the performance hit is holding you back, consider that the .Net framework or the JRE is many times slower than raw c code and a lot lot slower than x86 assembly.

My recommendation would be to start using ORMs.