Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
Microsoft’s Patterns and Practices group have produced a plethora coding patterns in the form of software blocks that has garnered a huge following in the .NET developer space. Of note is the Enterprise Libraries which packages various coding blocks, most notably the Data Access Application Block (DAAB) as a way to standardize the methodologies that architects designate as way to standardize the coding practices.
Over the past 12 months, I’ve noticed a big push towards DAAB as the foundation for .NET Framework data access strategies. In numerous conversations during my normal day to day interactions with customers, whether at conferences such as Tech Ed, face to face meetings or over the phone I’ve noticed a clear pattern emerging; the motivations of each architect are almost always different, but the goal is the same: build a ubiquitous common data access layer for use of all applications.
For a moment lets also consider the pulse with the .NET developer community: All activity seems suggests that the DAAB pattern has reached a tipping point and is being picked up as the defacto standard way to abstract your application away from the plumbing ADO.NET code even over and above the common programming model delivered in ADO.NET 2.0.Numerous resources exist on how, where and when to use DAAB. Take a look at these blogs, documentation and articles for details.
To build a truly ubiquitous data access layer, DAAB is an agreeable technical basis for .NET implementations. DAAB provides a clean interface driven leveling of data sources, but your client applications still remain badly exposed where SQL leveling is concerned.
So what is SQL Leveling and why does it matter to me if I want to become the rock star and deliver a truly future-proofed data access layer for my organization?
By definition, SQL leveling provides the capability to write a SQL statement that can be executed across multiple data sources, regardless of the data sources SQL implementation. If any of applications that uses your data access layer has to made even one coding consideration based on what data source it might be talking to, the value of your data access layer is quickly eroded.
Over the course of the next few postings, I will explore various aspects of SQL Leveling and hopefully leave you in little doubt that anyone serious about building a data access block with the Microsoft Enterprise Libraries Data Access Blocks cannot afford to ignore SQL Leveling.
View all posts from Jonathan Bruce on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.