The penultimate day...

In case anyone has been wondering where all this stuff takes place...

Architecture Decisions: DataSets or Objects

This was a very interesting discussion on a subject that I’ve been dealing with on a regular basis now. As I’m starting to develop more and more projects using .NET 2.0 I’ve been starting to use strongly types DataSets. It turns out I’ve actually been using Data Transfer Objects or DTOs. But that’s not important to anyone reading this really.

So the session was presented by a strong adovactor of object oriented programming. DataSets are a structure created by Microsoft, and by using them your tieing yourself to what MS will and will not let you do. Which for some companies this might be acceptable. In our case it’s possible we can accept these limitations in turn we would gain faster development and less code writing.

His recommendation however is to use Business Objects. To create a data layer (not necessarily a data tier). He advocated removing ALL business logic form the UI and presentation layers. Business logic would include ALL calculations, manipulations, validation and authorization. By remove he’s not saying you can’t do validation on the client or for UI objects. But those pieces of code should exist in a DLL library. MS has changed their data object on avg every 2.7 years so by using a BO data layer you keep a consistent architecture that is not tied to a passing MS phase. There hasn’t been any major OOP changes for close to 12 years (when interfaces were formally introduced). The biggest plus for using BO is that implementing  the IBindingList interface and the INofityProperyChanges interface would mean that your BO layer would already be compatible with the Windows Presentation Framework. Your BOs would bind to XAML based application without any (or little) modification. The downside is the ammout of code to implement a true OOP BO layer is much more significant. However it is a time tests approach with a clear upgrade path to .NET 3.0.

Visual Studio: Developing Local and Mobile Data Solutions with Visual Studio 2005

This was a very interesting session, its downside was being a level 200 it was more a talk and not so much of a how to. Mobile application are evolving and what starts off and a simple program for a single user soon becomes a multi-user distributed application. Once this happens more thought has to go into how the forms are crated to allow data to be accessed by multiple users.

Previously SQL Mobile filled this role but it was limited by liecencing restructions. SQL Express is more functional that most device application would need. The total foot print of the SQL Everywhere platform is less than 1.4MB. That’s right, it fits onto a floppy disk. The thought was to hand it out at TechEd on a floppy only they realized it would take most people more time to get data off a floppy (especially since most of us don’t have them anymore) than to just download it off the web.

SQL Everywhere gives only the functionally a standalone application needs. It runs in process so services don’t need to be installed onto the target machine. As such, there is also no support for stored process or other heavy database features since there is no advantage with the data store running in process with the application. This is the future of mobile device development database needs.

After this session I wanted to resolve an issued I’d always come across when it came to previous SQL Mobile attempts to create a simple smart device application. I ran through two of the Hands on labs for SQL Mobile (sadly there was no updates specific to SQL Everywhere and I would be unable to attend the syncing session for SQL Everywhere to SQL Server (have to catch my flight). I was able to resolve that my issue can now be solves with setting up a Publication for mobile devices. And I’m pretty sure Meena should be able to set that up now that she’s attended the Replication session.