dotNET Connections

Friday, September 28, 2007

DataDirect Design Previews & Architect Tutorials 2007

It is that time of year when we put in some serious airmiles to bring you all our vision on Data Connectivity and Mainframe integration futures. We are presenting both Boston, MA and Palo Alto CA over the next few weeks so don't miss your chance to hear our plans and of give your feedback...

Learn more about DataDirect's current product offerings and upcoming product enhancements at Design Previews. Designed to educate you about the future direction for DataDirect products, Design Previews are delivered via an open forum format so that your feedback can be factored into DataDirect's product plan.

DATES AND LOCATIONS

Tuesday, October 9th | Boston, MA - Westin Waltham
Wednesday, October 17th | Palo Alto, CA - Four Seasons - Silicon Valley

brought to you by

SPEAKERS INCLUDE:

Don't miss out - register today for this free educational seminar!

Register Now


---

Here is the letter for the Architect Tutorials:

New development platforms and emerging architectural standards are changing the way we view data - causing us to challenge long held views on data access technologies and demanding the use of new XML and service-oriented capabilities. Things are not as they used to be, and the landscape continues to evolve. Making informed choices facilitates rapid development and deployment and enhances application capability, scalability, and performance.

In this half day seminar, software architects will learn the state of the art in data access, mainframe integration, and XML query technology. We will provide the insight to navigate the complexities of data access technologies and the practical know-how to enhance application performance, flexibility and capability right away.

DATES AND LOCATIONS

Thursday, October 4th | St. Louis, MO - Hilton Frontenac
Thursday, October 11th | Toronto, ON - Westin Harbour Castle
Tuesday, October 16th | Irvine, CA - Hyatt Regency

brought to you by
co-sponsored by

SPEAKERS INCLUDE:

Register today for this free educational seminar!

Register Now

AddThis Social Bookmark Button

Tuesday, September 25, 2007

Is Quaere truly LINQ for Java?

The LINQ for Java question hit another milestone last week with the arrival of Quaere, although it remains to be seen whether this milestone is significant or not. We've certainly registered some false starts in this space which rightly have been seen as more marketechture than a true innovations on the Java platform.

Lets review some of the feature highlights...
  • Ability to perform queries against arrays or data structure implementing the Iterable interface.
  • An internal DSL (based on static imports and fluent interfaces) that lets you integrate the query language with
  • regular Java code. No preprocessing or code generation steps are required to use the DSL, simply add a reference to the quaere.jar file (and its dependencies).
  • A large number of querying operators including restriction, selection, projection, set, partitioning, grouping, ordering, quantification, aggregation and conversion operators.
  • Support for lambda expression
  • The ability to dynamically define and instantiate anonymous classes.
  • Many new “keywords” for Java 1.5 and later.

Compared to JLINQ discussed here, this seems like we have alot more meat similar to what is currently being offered in LINQ on the .NET Framework. Certainly the readers of dzone.com seem to feel it has merit, but no one seems to have asked the question: is LINQ on the Java platform actually a necessary innovation? Are there legions of Java programmers who are struggling with data access patterns that don't serve their needs ?

've talked about LINQ on number of posts; for the .NET community LINQ represents a quantum leap that changing the way developers search, sort and generally perform data access. Sure LINQ is not perfect, but it brings to bear many of the things Java developers have enjoyed for many years. One has only to examine the plethora of JDBC driver implementations and gauge the respect the JDBC specifications as the solid foundation for the success of Hibernate, the Spring Framework and many more. With the advent of JPA, I see the problem LINQ seeks to solve is even less acute in Java.

Don't get me wrong, while the effort underway with Quaere is admirable it could just all be an academic exercise. I am of course open to debate on that score...

AddThis Social Bookmark Button

Webinar: Converting your Applications to DataDirect Connect for ADO.NET

Another event in our series of ADO.NET online webinars:

Did you start developing your application using the ADO.NET providers supplied by your database vendor? Are you experiencing reliability or performance and scalability issues in your production environment? Are you frustrated by the limitations and the cost involved with dealing with the native database clients?

If so, join us for this technical webinar that will explain the benefits of replacing your existing ADO.NET provider with DataDirect's Connect for ADO.NET. These benefits are based on the fact that the DataDirect solution is 100% managed, which means that your applications will run faster, be more scalable, reliable and secure. We'll address how you can cut your development and deployment costs.

This webinar will walk you through the steps necessary to convert your applications so that they can fully leverage the benefits of the Common Language Runtime. These benefits are tied to the fact that the DataDirect Connect for ADO.NET database provider is 100% managed.


Join us for our EMEA / East Coast time or our PST / Asiapac time...

AddThis Social Bookmark Button

Thursday, September 6, 2007

How to bullet-proof the Data Access Application Block (DAAB)

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.

AddThis Social Bookmark Button