The SilkBuilder ORM

SilkBuilder is SQL's Missing Friend! Unlike most traditional ORMs that attempt to hide raw SQL under the guise of "pure OOP development," SilkBuilder's ORM utilizes SQL as the primary method for querying and interacting with data. In this way, the ORM serves as a communication channel, honoring the database's authority over data management and storage.

SilkBuilder views the database as an object-oriented programming (OOP) package. This package consists of classes or tables. Each class possesses dynamic properties that correspond to the columns of the table or the columns returned by a SELECT statement. The class also includes methods for selecting, inserting, updating, deleting, and executing operations. Additionally, it features events, which are also known as triggers.

The problem with traditional ORMs

While ORMs aim to simplify database interactions and boost developer productivity, many developers express a strong dislike for them, often citing a range of practical and philosophical issues. Based on discussions from developer communities, blogs, and social media, here are the most common reasons why ORMs attract criticism, which stems from experiences in larger, more complex projects.

  • Performance Overhead and Inefficient Queries

  • Leaky Abstractions and Loss of Control

  • Object-Relational Impedance Mismatch

  • Encourages Ignorance of Database Fundamentals

  • Complexity and "Magic" in Implementation

  • Schema Duplication and Maintenance Hassles

What SilkBuilder ORM offers?

Instead of creating an object-oriented abstraction of the database, the SilkBuilder ORM directly uses SQL queries as part of the class configuration, loading them dynamically. This "class creation" process does not require compilation into a .jar file or adding it to the CLASSPATH. As a result, this approach addresses the disadvantages associated with traditional ORMs in this way:

  • Query performance relies on an optimized database structure and a well-crafted SELECT statement. Query performance can be tested in the database client before adding it to SilkBuilder ORM.

  • There is no abstraction or loss of control when using raw SQL Queries.

  • Minimal Object-Relational Impedance Mismatch because each table is considered a kind of Class with dynamic data properties.

  • Harvest the expertise and knowledge of Database Fundamentals.

  • There is no hidden "magic", just the well-known raw SQL statements.

  • Greatly minimizes schema Duplication and Maintenance by respecting the database authority over the data structure and storage.