CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
PowerBuilder is evolving into a .NET Framework 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.
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 ( Windows Presentation Foundation ).
The ADO.NET Entity Framework enables developers to create data access applications by programming against a conceptual application model instead of programming directly against a relational storage schema. The goal is to decrease the amount of code and maintenance required for data-oriented applications. Entity Framework applications provide the following benefits:
- Applications can work in terms of a more application-centric conceptual model, including types with inheritance, complex members, and relationships.
- Applications are freed from hard-coded dependencies on a particular data engine or storage schema.
- Mappings between the conceptual model and the storage-specific schema can change without changing the application code.
- Developers can work with a consistent application object model that can be mapped to various storage schemas, possibly implemented in different database management systems.
- Multiple conceptual models can be mapped to a single storage schema.
- Language-integrated query (LINQ) support provides compile-time syntax validation for queries against a conceptual model.
ADO.NET Entity Framework abstracts the relational (logical) schema of the data that is stored in a database and presents its conceptual schema to the application. For example, in the database, entries about a customer and their information can be stored in the Customers table, their orders in the Orders table and their contact information in yet another Contacts table. For an application to deal with this database, it has to know which information is in which table, i.e., the relational schema of the data is hardcoded into the application.
The disadvantage of this approach is that if this schema is changed the application is not shielded from the change. Also, the application has to perform SQL joins to traverse the relationships of the data elements in order to find related data. For example, to find the orders of a certain customer, the customer needs to be selected from the Customers table, the Customers table needs to be joined with the Orders table, and the joined tables need to be queried for the orders that are linked to the customer.
This model of traversing relationships between items is very different from the model used in object-oriented programming languages, where the relationships of an object’s features are exposed as Properties of the object and accessing the property traverses the relationship. Also, using SQL queries expressed as strings, only to have it processed by the database, keeps the programming language from making any guarantees about the operation and from providing compile time type information.
The mapping of logical schema into the physical schema that defines how the data is structured and stored on the disk is the job of the database system and client side data access mechanisms are shielded from it as the database exposes the data in the way specified by its logical schema
