This site's content was compiled from 1993 to 2006. Beyond that, Google is your friend.
Object Tools GmbH
DALE aims to make access to relational databases as simple and flexible as possible by providing a seamless transition from the "object world" of Eiffel to the "table world" of RDBMS (relational databases).
Alternatively, DALE will allow you to to access a Database in a flexible but not necessarily object-oriented way. This gives you the same possibilities as in other languages - but nothing more.
In each case the starting point of all applications written with DALE is the database, i.e. if you want to make a new design, design the database at first and let the wizards help you in writing your classes. This approach was chosen for several reasons:
There are three basic principles of DALE:
Power and flexibility. Being object-oriented presentation of ODBC, DALE acquires all the power and flexibility of ODBC. On the other hand, DALE is not just an Eiffel interface to ODBC API; it also extends the functional possibilities of ODBC, hiding as much extra code from application developer as possible. It is also possible in DALE to use native functionality of a data source that is not supported by ODBC.
Simplicity. This means not only the simplicity of code solving a given task, but also the ease with which application developers can find out how to write that code. Although DALE allows you to solve every task that ODBC can, you don't have to learn it all at once. The principle is: the simpler the problem, the simpler the solution. For example, you can create and send a query and recieve the results in four different ways - depending on what you have and what you want. In accordance with the principle above, you only need to know the simplest way and can use it until you realize that you need something more.
Open architecture. DALE is not just for creating finished applications. For advanced applications and groups of applications you can define intermediate abstractions for database objects. For example, DALE contains such classes as DB_TABLE and RECORD presenting a notion of the database table and record respectively. You can define two new problem-oriented abstractions for them, for example, PEOPLE and PERSON adding new features, for example, the validation of record integrity into PERSON, etc.
