You don't have to worry about field orders, and can use field completion in the IDE. It's much more convenient to type People. then select the Name property, and access to its value.

The ORM code is much more readable than the SQL. You don't have to switch your mind from one syntax to another, in your code. You can even forget about the SQL itself for most projects; only some performance-related or complex queries should be written in SQL, but you will avoid it most of the time. Think object pascal. And happy coding. Your software architecture will thank you for it.

Another good impact is the naming consistency. For example, what about if you want to rename your table? Just change the class definition, and your IDE will do all refactoring for you, without any risk of missing an hidden SQL statement anywhere. Do you want to rename or delete a field? Change the class definition, and the Delphi compiler will let you know all places where this property were used.

Another risk-related improvement is about the strong type checking, included into the Delphi language during compile time, and only during execution time for the SQL. You will avoid most runtime exceptions for your database access: your clients will thank you for that. In one word, forget about field typing mismatch or wrong type assignment in your database tables. Strong typing is great in such cases for code SQA, and if you worked with some scripting languages (like python or ruby), you should have wished to have this feature in your project!

It's worth noting that our framework allows writing triggers and stored procedures (or like-stored procedures) in Delphi code, and can create key indexing and perform foreign key checking in class definition.

Another interesting feature is the enhanced Grid component supplied with this framework, and the AJAX-ready orientation, by using natively JSON flows for client/server data streaming. The REST protocol can be used in most application, since the framework provide you with an easy to use "Refresh" and caching mechanism. You can even work offline, with a local database replication of the remote data.

For Client/Server aspect, you don't have to open a connection to the database, just create an instance of a TSQLRestClient object (with the communication layer you want to use: direct access, named pipe or http), and use it as any normal Delphi object. All the SQL coding or communication and error handling will be done by the framework. The same code can be used in the Client or Server side: the parent TSQLRest object is available in both side, and its properties and methods are strong enough to access the data.