WTF: Why create an ORM toolkit?
A: Because we have worked with most ORM's for C# and Java, utilizing both open-source projects and
applications from private companies.
We have found the available toolkits/frameworks are extremely large, and only a few parts are ever used.
Most of the frameworks generate horribly inefficient queries for the most simple of lookups, and they tend to perform queries much more often than necessary.
And the most irritating thing about most ORM's is that they have features which appear to be useful to the developer, but are extremely expensive in the use of server and/or database resources when misused.
The reason we initially created HORK was to create entities that would replace existing code for EntityFramework with the least amount of code changes.
The entities in EntityFramework will have the same properties as entities in HORK if created from the same database. To switch-out EntityFramework with HORK you just need to change how entities are created (usually where DBContext lives), change the method names for CRUD operations, and then replace any LINQ queries with HORKQueries.
WTF: Where can I get HORK?
WTF: How does it work?
A: Most ORM's allow users to develop the database first, or to develop the layout of the ORM code first.
HORK works exactly the same way. You can run a utility that will query the tables you configured and generate the related Entity classes, or you can edit a configuration file and use it to generate the related Entity classes.
And that is all there is. Once you have generated the Entity classes from the database or code you are done with setup and you can go directly to developing your application!
WTF: How difficult is it to re-use HORK across applications?
A: We made it very simple. HORK is comprised of one DLL. When you setup your database entities, HORK
will generate entity classes that depend on the DLL.
You can take the DLL and the generated entities and move them to any system or platform which supports .NET or MONO.
WTF: What did you do to make HORK faster than most ORM's?
A: There were a lot of things that we found ORM's were doing which were grossly inefficient, and we decided not to do the same things:
- Features in code that replace what the database can do.
- Utilizing code reflection to determine class types at run-time.
- Caching past changes and/or maintaining change history.
- Hooking into triggers and other database features to try to detect table changes.
- Trying to calculate if a deadlock may/will occur.
- Wrapping SELECT queries with transactions.
- Using language-specific features such as LINQ to reduce development time.
LINQ can produce inefficient SQL, and allows developers to create code that can result in numerous queries for a simple operation.
- Use of class-based meta-tables by creating queries which cross tables and produce a generic 'query result' type.
All database clients perform this same operation without needing any extra layers of abstraction. (.NET DataReader, Java ResultSet, etc.)
- Not utilizing a dynamic SQL query generator.
- Not utilizing the most direct access to the database.
Many ORM's add an abstraction layer which is much slower than going directly to the database using native driver types.
- Protect the developer from having to know anything about the database.
We have found that to make any ORM perform and work well, you need to know a lot about the ORM, the backing database technology, and the database schema.
Many of the features you won't find in HORK are those that are used the least in other ORM's or are very computationally expensive.
Please contact us if you have any questions or comments about HORK:
- hork at saladforkranch dot com