This project is read-only.
Project Description
{QuickToAD, pronounced 'quick toad' and stands for ‘Quick To Application Development’, is a foundational development project for the purpose of jump-starting data-driven application projects. While it is a work in progress, when complete, it will consist of .net class libraries that aim to support all the critical features that a modern data-driven line-of-business (LOB) application would need. For example, email/message handling, reporting, importing/exporting, staple user interface controls such as navigation, security, grids, etc., data resource tables such as zip code data, time zones, countries, localization, etc., integration with other frameworks - open source and commercial, and many other things too numerous to list. The premise of this framework, or scaffolding, is primarily designed to be used as a foundation for any data-driven project that would be web, API, or mobile based and depends on .Net and SQL Server as its primary backend platform. This project is not designed to suggest a specific development approach over any other. It consists of proven, reliable methodologies that have been used in many enterprise level solutions and continues to be a mainstay in its ability to adapt and expand as new technologies come and go.}

No Debates - Just Use It if You Need It
{Philosophically speaking, data-driven applications bear no resemblance to MVC or MVVM design patterns primarily because data- driven minimizes OOP in an attempt to put greater focus on the data integrity of an application and 'consuming' it in many different ways over the long-haul. Point of interest - the persistence layer (which I find the term to be offensive on behalf of database management systems everywhere) can and will be accessed directly in a myriad of ways, so it is of the essence that a data-driven app uses the database as the system of record for data integrity and data definition; which can pose challenges because of the lack of OOP at this level.

While data-driven applications do define the data by means of the database, the assumption is that the data does not need to be described explicitly for it to be useable or accessible - only that the client accessing the data understands what it means. That does not preclude one from using objects and models with a data-driven application, but the approach would be to generate those models and objects dynamically in the context of where they are needed and will be consumed. But the real goal, in my opinion, is to emphasize the data's long term persistence and integrity in an attempt to minimize the mechanics of how it got there in the first place. Reason being, user interface technologies will come and go over a lifetime, but the data and its meaning persists forever; and we dare not predict what technology lies ahead that will sit between the human and the data itself - so if you are 'all in' on MVC/MVVM today or even a specific language, it's not if you will have to rewrite everything to make your app work in the future, but when.

Thankfully, with a data-driven approach, your data stays safe and completely decoupled from any specific language or technology that put it there, always ready to serve up meaningful data as required. For example, if you have a 'Customer' table that contains a customer's name and the last sale amount, I will need to access that information in many different ways over an unknown time period. How the data got there is of no importance to me, only that I know it is stored as valid and that when I access the data, it is valid. I may use a SQL query, a reporting engine, an API, or a traditional web app to read that data. It does not matter to me what the technology is because I am interested in the data and how it is described by the database. This is an important facet of data-driven applications, because unlike OOP, the main goal should be to enforce data integrity no matter what happens over time. Whereas the typical OOP design using ORM to talk to a persistence layer allows for the meaning of data to change because referential integrity is not guaranteed and maintained within the storage mechanism, but rather at the mechanism that provides for the creation of that data.

In short, when it comes to LOB applications that require a multitude of interfaces for data consumption and data generation, data-driven applications stand the test of time. Though not without its challenges, it is just as extensible, flexible, and maintainable as its MV/OOP-centric counterparts when done properly. QuickToAD aims to be the foundation that gives anyone interested in using a data-driven approach, a jump-start to begin developing the core features of their app, rather than having to design and build all the basic needs from scratch. I hope you find this project as useful as I do!}

Last edited Oct 7, 2012 at 5:31 AM by sizzlefinger, version 2