The purpose of this post is to walk you through a demo application I’ve written using a few different technologies, tools and patterns as listed below:
- SQL Sever vNext
- MVC Pattern
- Proxy Pattern
- Memento Pattern
My language of choice and the one used for this application is C++, reason being is that I could easily compile this solution for any other platform and it will just work; but C++ is also a modern and elegant language that allows me to do anything I want.
Another point I’d like to make is that patterns are language-agnostic, languages the way I see them are just syntactic sugar that allow developers to express themselves. In my personal case, both English and Spanish enable me to express differently (mainly because of the cultural differences) but the message remains the same.
I think that the best way to get started is by setting up SQL Server vNext on an Ubuntu VM and then describe the bits and pieces of the demo application. My main operating system is Linux (I think that’s one of the reasons why I’m not an MVP any longer) because it just simply works and performs heaps better than other OSes (most supercomputers runs Linux, for instance).
Most applications regardless of the technology and framework used to build them provide a DataContext (or BindingSource). Its purpose is to store a local offline copy of the required data retrieved from a backend system (e.g.: RDBMS or Web Service, for instance).
Main reason for this is performance and flexibility, connection is established with backend for updates only and then all of the networking plumbing comes into play, this is by far more efficient than having a dedicated connection (socket) that might be idle most of the time, so if you’re a developer reading this, and in your code you usually keep a connection I would strongly suggest you to revise your design. In the demo application, I provide the DataContext functionality in the class with the same name.
Data coming from the data source is stored in a std::vector of ContactModel. Navigation is done on this vector, as well as databinding so it’s crucial to keep it in sync with backend. The ContactModel also has an indexer that allows retrieving the value of a property by its index.
Data types in use are mainly std::string. Since ODBC’s API is C-based, the ContactModel has also got a property (member) called ODBCFields that directly map to their corresponding ODBC datatypes. Changes made to the database from the application can be verified via SQuirreL as depicted below.
I find it funny and hilarious to a certain extent the fact that I can connect to SQL vNext on Linux via ODBC (even from Excel) but I cannot do it from Visual Studio.
Reason being is that ODBC implements TDS (inherited from Sybase, yes… SQL Server “was” a Sybase product which Microsoft would commercialize for Windows and Sybase for *nix systems) whereas Visual Studio uses the ADO.NET Data provider which can connect but doesn’t recognize it as a compatible SQL Server instance, so what’s the parable here?
Stick to standards as much as possible, trends and “fashion technologies” will always come and go over time, but standards will last much longer.As stated earlier, the application implements the following patterns, and their corresponding implementation in the demo application :
- MVC: The model is bound to the View via the DataContext in the MainWindowController.
- Singleton: There’s an static instance of the MainWindowController called self (equivalent of this exposed to static and external methods) which is initialized the first time the application starts, it hold references to Controls and functionality in the controller.
- Proxy: Some functionality in the Parent or container class (MainWindowController) is passed across to children object as explained in previous post here.
- Memento: When an edit takes place whether it’s because of a new record or making changes to an existing record, the current record is stored and it can be restored if edit is cancelled.
And that’s it, folks!
Please feel free to download source code from here