http://reddevnews.com/news/article.aspx?editorialsid=10472

I've pasted in my quote from the artile below, as it is very representitive of our position on where LINQ to SQL and where the ADO.NET Entity Framework fits in the general .NET data access landscape.

' "I don't think the Entity Framework is necessarily perfect, but I think it's going to change the outlook of data access in .NET," said Jonathan Bruce, ADO.NET technologies program manager at DataDirect, which is a subsidiary of Progress Software Corp. "I think LINQ to SQL will likely find its niche in small, in-house proof-of-concept type projects because it's easy to get going -- it has a very lightweight data model." '

You can hear a great discussion on this topic, "Bullet Proof your Data Access on the .NET Framework", an online webinar we did with the Stephen Wynkoop a SQL Server MVP, and founder of SSWWUG. Check out the link below to listen into the discussion.

http://www.datadirect.com/connect-webcast-archive-data-access/index.ssp

http://www.devtopics.com/top-10-net-news-stories-of-2008/

---

DataDirect Technologies Continues to Set the Standard for Superior Data Connectivity
to the .NET Platform

Latest Release of DataDirect Connect® for ADO.NET Includes New Performance Features and First-of-its-Kind Bulk Load Functionality

BEDFORD, Mass. – Dec. 8, 2008 – DataDirect Technologies, the unparalleled leader in data connectivity and mainframe integration and an operating company of Progress Software Corporation (NASDAQ: PRGS), today announced the latest release of its DataDirect Connect® for ADO.NET data providers. With DataDirect Connect for ADO.NET, developers can securely and efficiently write and deploy .NET enterprise applications that connect to multiple databases including Oracle, DB2, Microsoft SQL Server and Sybase. The latest product release includes new provider features for each major database, new performance tuning options and introduces DataDirect Bulk Load, the most flexible, common API-based implementation of bulk-load functionality for the .NET platform that provides consistent semantics across all supported databases.

DataDirect Connect for ADO.NET has raised the bar for superior performance, security and interoperability. As the only suite of ADO.NET data providers with a 100 percent managed code architecture, DataDirect Connect for ADO.NET eliminates the need for database client libraries. Because managed code runs in the Common Language Runtime (CLR) environment it reduces risks and closes holes that unmanaged code leaves exposed, providing developers the most versatile deployment options available in both application and client-server environments.

“Database vendors offer the bare minimum in terms of data connectivity, and this just isn’t enough for large scale, complex applications,” said John Goodson, vice president and general manager at DataDirect Technologies. “With DataDirect Connect for ADO.NET developers get full support for the .NET Framework with the fastest and most functional ADO.NET managed data providers on the market.”

Building on its reputation for technical innovation and reinforcing the company’s steadfast commitment to responding quickly to the needs of software developers and system architects, DataDirect Technologies has included DataDirect Bulk Load in the latest version of its data provider. A persistent data connectivity challenge is the need to load very large amounts of data into a relational database as fast as possible. For developers working with more than one database, DataDirect Bulk Load offers a standard and consistent method for moving volume-intense data across Oracle, DB2, Microsoft SQL Server and Sybase databases, without having to deploy and load client libraries.

In addition to the new levels of efficiency brought by DataDirect Bulk Load, the latest release of DataDirect Connect for ADO.NET also offers key performance enhancements. New tuning options provide optimal performance in a wide variety of application scenarios allowing users of Oracle, DB2, Microsoft SQL Server and Sybase to reap substantial performance and efficiency gains with no changes to their applications.

Corporate IT departments at the Fortune100 and leading ISVs use the DataDirect data provider to build reliable .NET applications that can connect to multiple databases while reducing the amount of code necessary to utilize database-specific features. With its deep rooted, technical relationships with all major database and platform vendors, DataDirect Technologies ensures its data connectivity products support the latest provider features and database versions. DataDirect Connect for ADO.NET now supports Oracle 11g R1, Microsoft SQL Server 2008, DB2 iSeries V6R1 and includes many new performance and usability features. To view a complete list of database provider features, go to: http://www.datadirect.com/products/net/index.ssp

About DataDirect Technologies
DataDirect Technologies is the software industry’s only comprehensive provider of software for connecting the world’s most critical business applications to data and services, running on any platform, using proven and emerging standards. Developers worldwide depend on DataDirect® products to connect their applications to an unparalleled range of data sources using standards-based interfaces such as ODBC, JDBC™ and ADO.NET, XQuery and SOAP. More than 300 leading independent software vendors and thousands of enterprises rely on DataDirect Technologies to simplify and streamline data connectivity for distributed systems and to reduce the complexity of mainframe integration. DataDirect Technologies is an operating company of Progress Software Corporation (NASDAQ: PRGS). For more information, visit www.datadirect.com.
# # #

DataDirect and DataDirect Connect are trademarks or registered trademarks of Progress Software Corporation or one of its subsidiaries or affiliates in the U.S. and other countries. Java and all Java based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Any other trademarks contained herein are the property of their respective owners.

I'll post all responses and suggestions I see on this and my sister blog dot-Net Connections.

October 1st - Seattle, WA – Hyatt Regency Bellevue
October 21st - St. Louis, MO – Hilton St. Louis Frontenac
October 28th - Toronto, ON – The Westin Harbour Castle

First, our the DataDirect Architect Tutorials. Topics at these locations include: "DataServices Update with Industry Expert ZapThink", "Designing Data Access in a SOA Environment" and "The New Reality: Data Access for Virtual Environments" and you can hear these talks, meet the speakers.

October 2nd - Palo Alto, CA – Crowne Plaza Palo Alto

October 16th - Boston, MA – - Boston Marriott Burlington

Next, our Design Previews our long running annual series of talks where we "Frontiers in Data Access:The Coming Wave in DataServices", "Product Roadmaps: Connect and Shadow & XML", "SaaS: How Does it Effect Your Data Access Strategy", "How DataDirect Shadow Can Enable ISV’s Applications for Accessing Mainframe Data" and last, but certainly not least "XQuery And The DataDirect XML Data Integration Suite".

See you there!

Before I begin though, I should make a comment about the reason for this series. After many conversations with .NET developers and with development organizations using .NET, we have heard a lot of confusion over the different approaches to accessing multiple databases in .NET. In some cases, what we have heard misinformation, in some cases it was a lack of information. In most cases, though, people just had different sets of needs and experiences and those differences often dictated a different set of requirements for everyone we spoke with. So what I'm offering isn't intended to be the "final" answer on this matter - merely a set of advice and guidelines based on our experience with this subject and with others who have wished to learn more about if for themselves.

With that said, the most obvious place to start when discussing how to develop an application that requires access to multiple relational data stores is to talk about ADO.NET. Historically (and even today given the many announcements concerning the ADO.NET Entity Framework), building code that accesses the ADO.NET interfaces directly is easily the most prevalent approach in use today in .NET applications. If you’ve ever built an ASP.NET application that connected to Oracle and used Visual Studio tooling to do it, then the database access code that was generated used ADO.NET under the covers.

The Pros – Coding directly to ADO.NET is perhaps the best option for those experienced developers that have a strong background in ADO.NET, want to maintain fully control of their data and require the power of the database to be at the immediate disposal. Coupled with this, writing to ADO.NET allows for very granular control of database access code which can be leveraged to ensure the most efficient database access for a particular application. Put simply, if you know what you’re doing with ADO.NET, you can probably do a very good job coding your application with this approach.

The Cons – All of that granular control means that a significant amount of application development time will likely be required. In addition, the developer will need to know which ADO.NET providers will be used ahead of time. Finally, unless the developer is a thorough planner and careful coder, he or she can fall into the trap of using provider-specific code. Unfortunately many developers are unaware of these factors during the initial development phase. As a result, it isn’t until after a significant investment of time and effort has been made that the impact of these factors becomes apparent.

The use of Visual Studio tooling during development isn’t inherently bad, nor are most developers coding without some foresight into what they are doing. Unfortunately, there is a natural tendency to take the path of least resistance. This tendency, combined with a certain level of code abstraction that Visual Studio tooling can create, often leads to applications that are mired down in huge masses of provider-specific code.

While this result might be acceptable for single data source data access (e.g. SQL Server only), it does lock the application to the provider it was originally written to work with. Consequently, adding support for additional database providers ultimately becomes a huge headache as application code and SQL statements must all be rewritten to account for differences in provider code, semantics, and SQL statement formatting. Ask anyone who has been faced with this situation and they will tell you that it’s a nightmare to deal with!

It is worth noting that that the use of connection factories (link) can reduce the amount of provider-specific code with this approach. While this does not account for and eliminate all provider-specific coding in this approach, it can help mitigate some of the hassle of trying to support multiple providers and data sources.

So, to summarize:

Coding Directly to ADO.NET

Pros:

• Available today
• Allows granular control of database access code
• Best option for developers with a strong background in coding to ADO.NET spec

• Requires careful coding on the part of the developer to avoid provider-specific code where possible
• Requires more development time as compared with other approaches
• Requires prior knowledge of what providers will be used or recoding to add support for additional providers
• Applications tend to get locked to a specific provider

My next post will cover an approach specifically designed to help architect .NET applications requiring heterogeneous data access – programming with the Microsoft Data Access Application Block.

So, welcome Mike!

______________________

Thanks, JB. Comments and descriptions of the advantages and benefits of developing software using Microsoft’s .NET environment are easy to find – there are websites and blogs galore that go into these details ad nauseum. Unfortunately, finding a clear, concise comparison of the different approaches to developing or modifying a .NET application to access multiple data sources has been next to impossible…until now. ^_^

This is part one of a series of posts aimed at untangling the web of options and technologies available for heterogeneous data access in .NET. Each posting I will introduce an approach and explain its benefits and drawbacks as well as its options and limitations. By the time this series is concluded, we will have a nice summary of information all in one place that will allow anyone to make an informed assessment of the right approach for any project or organization no matter how great or small.

We were delighted to be able to participate in today's announcements too. I'll leave it to John Goodson, to sum it up:

""DataDirect Technologies is delighted to see the ADO.NET Entity Framework RTM," said John Goodson, vice president and general manager of DataDirect Technologies. "We are firmly committed to the ADO.NET Entity Framework and look forward to offering Oracle connectivity in the near future."

I expect to able to talk alot more about the ADO.NET Entity Framework and Connect for ADO.NET on this blog, very soon.

The mainframe world, all too often associated with legacy systems that exist in some dark corner of buildings continues to this day to provide the essential back bone for many corporations essential and business-critical applications. While some companies seek to migrate data out of mainframe investments into data bases such as Oracle, or often SQL Server there are plenty who'd rather leave these resources well alone and bring on stream more up to date interfaces to these data asources.

That said, development platforms such as Java and the .NET platform however enjoy the majority of developer focus today and resources such as DB2 z/OS and non relational mainframer esources such as VSAM, IMS and Adabas get left behind.

Our solution? Shadow for ADO.NET. Available for use with the Shadow z/Direct product line, DataDirect's mainframe integration software stack. We are very proud of the work we've done here, so let me call out some of the major features:

• Integration of mainframe DB2 and VSAM data
• 100% managed code provider
• Support for the .NET Framework 2.0, 3.0 and 3.5 on 32-bit and 64-bit platforms
• Support for ADO.NET 2.0 Common Programming Model
• Runtime compatibility with Visual Studio
• Support for a Metadata Collections based on the ANSI SQL Information Schema specification as well as collections specific to CICS and VSAM
• Support for common methodologies used to manage auto-generated values