Open Source O/R Mapper and Code Generator by Adam Rackis M.S.      OR.NET
Created for the .NET 2.0 Framework and Microsoft SQL Server   DOWNLOAD

Overview

Welcome to OR.NET, an open source O/R Mapper and Code Generator for the .NET 2.0 Framework. OR.NET generates a comprehensive data access layer in stand-alone C# 2.0 after scanning your database’s meta-data. This process creates all relationships based on both simple foreign keys, and many-to-many mapping tables. All identity columns will be found, and treated appropriately for inserts, and all nullable fields will be created as nullable properties in code. The generated code will allow you to treat objects as objects, and not database rows - in other words, you will NEVER have to manually assign foreign keys to your objects (though doing so won't hurt). Just assign objects to other objects, or add objects to collections, and OR.NET will assign foreign keys appropriately.

In addition to automatic class structure generation, you can also manually create / modify classes by specifying which column(s) represents the key, which columns to create properties out of, and which other objects the new class links to, either through a foreign key, or a many-to-many mapping table – all through an exceedingly easy to use GUI.

The classes generated are completely database independent, with all data-access happening through generated assembler classes. This means that the actual classes have a small footprint, and can be fully serialized, for example across a web service, or on the ASP.NET ViewState.

OR.NET transparently manages all foreign key relationships, and many-to-many relationships for you. Simply assign any FK-related objects, or add or remove objects from any collections, and when you save the parent object, all children will be updated, and assigned their foreign keys, and (if applicable) their newly-created identity-column-based keys. For many-to-many collections, removed objects will have their link entries deleted, and added objects will have their links saved (the object will still be inserted or updated, if necessary). For foreign key collections, removed objects will be deleted.

All SQL Commands are fully parameterized, and therefore resistant to injection attacks, and also slightly better performing due to SQL Server’s caching of execution plans.

By default, all SQL Update, Insert, and Delete operations are transaction based. This option can be turned off simply by using a method overload, and passing an additional boolean parameter, if desired.

Reading, updating, and deleting objects all happen through intuitive methods inside of the generated assembler classes.

Reading: There are two ways to read objects using OR.NET generated code. The first is to leverage the simple methods in the assembler classes. These include reading a single object by key, all objects existing in the DBMS, or a single or collection of objects corresponding to a hand-written SQL WHERE clause.
OR.NET also supports more robust ways of reading in persistent objects through the generated criteria classes. Criteria classes allow you to specify various criteria on the object properties themselves. You then pass the criteria class to the assembler, which retrieves the objects from the database matching the conditions you set.
Updating: The assembler classes have a method called MakePersistent. This method has various overloads which allow you to specify transaction support, and whether or not to save all children objects as well.
Deleting: Deleting is handled through a delete method in the assembler class. This method will remove the object in question, as well as any many-to-many links it has.

Customization

All operations OR.NET performs happen through generated code. This means that if you're ever curious / unhappy about how a particular operation happens, you're free to look at the generated code, and change it to suit your needs (just be careful to put any changes in a separate file so you don't re-gen over your changes).

What's the catch?

Well, this level of customization and intuitiveness comes with a price. The price is that a fairly large (but not obscene) amount of code is generated. So, if you're working on an enterprise level application with hundreds of DB tables, you might want to go try something a little more robust / less easy to use, such as NHibernate or LLBLGen. Then again, if you're working on an enterprise level application with hundreds of DB tables, it's unlikely you're out on the internet looking for open-source O/R Mappers :)