PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: CRM, PowerBuilder

CRM: Article

How Might Entity Framework Affect Us?

There may only be one thing missing for us to be able to take advantage of EF out of the box

If you've been following the product direction for PowerBuilder for the last few releases, and particularly with respect to the upcoming PowerBuilder 12, you know that PowerBuilder is evolving into a .NET development tool. As PowerBuilder developers, you'll also know that the key strengths of the product are its productivity through Rapid Application Development (RAD), support for object-oriented programming (OOP), and simplified data access and update through the DataWindow.

That last item, the DataWindow, has served us well. No other control out there gives us the same capabilities. And Sybase has continued to expand on those capabilities, giving us new features like web services as a data source, TreeView presentation styles, and (in PowerBuilder 12) a fully managed version that supports WPF.

The one area that the DataWindow has lagged in is that it co-mingles the presentation and data access layers of our application (http://xrl.us/bgfq6p). Of the six available data sources for a DataWindow (see Figure 1), four of the six involve direct access to a database. The fourth of those six options (stored procedure) does allow us to add some logic between the DataWindow and the underlying tables, but still required a direct database connection. Only the most recent option (Web service) has decoupled the DataWindow from direct access to the database.

Figure 1

Such co-mingling has restricted the ability of the DataWindow to be used in distributed applications, requiring non-standard constructs (e.g., passing blobs from GetFullState and SetFullState) in order to pass data from the presentation to the data access layers of our application. It has also required that DataWindow technology be present in both layers, dramatically restricting interoperability.

That's where Entity Framework (EF) may actually give us some help. Microsoft released the second CTP of EF 4.0 last month in parallel with the second beta of Visual Studio 2010 and the .NET Framework 4.0. One of the new features in EF of particular importance for this discussion is the addition of support for "POCO"s - plain old CLR objects (http://xrl.us/bgfq6g). POCOs are particularly useful as Data Transfer Objects (DTOs) in distributed systems (see http://xrl.us/bgfrax and http://xrl.us/bgfrby).

EF would then provide us with two things:

  1. It provides object-relationship modeling (ORM). If you're like me, one of the big reasons you like the DataWindow is because you hate coding SQL all the time, particularly SQL to implement trivial retrieve and update operations. That what ORM does for you. It creates "domain model objects" (http://xrl.us/bgfrc9) that perform the trivial retrieve and update operations for you, and expose them through objects with methods that behave like any of the other objects in your application.
  2. It handles the mapping between domain model object and the POCO. All of the state information is maintained by EF within the domain model. We don't have to worry about creating an "assembly" or "implementation" class to maintain the mapping between the domain model object and the POCO.

In fact, there may only be one thing missing for us to be able to take advantage of EF out of the box. If you look at the data source options for a .NET DataGridView, you'll note that it has one other option besides the database and web services options that the DataWindow provides (see Figure 2), the Object option. This allows you to specify a .NET class that will be used as the data source. For an example of how simple it is to map an EF class to a DataGridView as a result, see http://xrl.us/bgfrdy.

Figure 2

What the DataWindow would need is the ability to also accept a class as a data source. Note that once it did that, we would even further decouple the DataWindow not only from the database, but from the source of the data entirely. It would no longer matter where the data behind the class originated; it might be locally through EF communicating directly to the database, or it might be through distributed services that simply interact with our application through the POCOs. That latter approach will become particularly important should cloud computing gain momentum.

The real question perhaps is whether EF will actually take off. So far, it hasn't. Nor has NHibernate (the .NET version of Java's Hibernate) really seemed to have developed significant mindshare. Perhaps, much like previous Microsoft technologies, it won't be until the third or fourth major version that developers feel that it's feature complete enough to take notice and start using it in significant numbers. If that is the case, the upcoming release of 4.0 may be the tipping point (which is really the third major version, since they skipped from EF 2.0 directly to EF 4.0).

I've become a big fan of object-relational mapping. As an Oracle database shop, my company has been implementing something similar to it within the database itself (Table APIs using PL/SQL objects) for years. However, I find that many of the PowerBuilder developers I know struggle with the idea of giving up coding the SQL select directly in the DataWindow. They're comfortable with the co-mingling of the presentation and data access layers, and see the separation of them as twice the work with no real perceived benefit. (For that matter, .NET developers appear to feel the same, given the lack of acceptance of EF, NHibernate, or LINQ to SQL to date.)

What do you think? If the DataWindow supported classes as data sources, would you consider EF 4.0?

More Stories By Bruce Armstrong

Bruce Armstrong is a development lead with Integrated Data Services (www.get-integrated.com). A charter member of TeamSybase, he has been using PowerBuilder since version 1.0.B. He was a contributing author to SYS-CON's PowerBuilder 4.0 Secrets of the Masters and the editor of SAMs' PowerBuilder 9: Advanced Client/Server Development.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.