Object Relational Mappers

To anyone who has any kind of experience building business applications that utilize a database, read on:

Of all the leaps and bounds that .NET brought us in the programming arena, there is still something missing: object relational mapping. I know MS is planning to build the ADO.NET Entity Framework, but who knows how good it will be or how long it will take them to build it? We all know object relational mapping is the future.

I've seen many different ORM tools for .NET out there, but I'm not satisfied with any of them. Half of them are free and the other half you have to pay for. I have an idea for a tool that would satisfy all my requirements. It would be free, efficient, extremely flexible, would not require your business objects to derive from a base class or interface.

I was wondering if anyone has any comments/criticism of my idea. If you're intrigued I'll post some more information. Also, I was thinking about turning it into a project on these forums, but I'm not sure.

Anyways, anyone who reads this please post your thoughts, no matter how short!

How is it different from Visio and VS2005's Class Designer?

Interesting concept.

How do you propose to implement such a model?

Quote:

---

Originally Posted by mendhak

How is it different from Visio and VS2005's Class Designer?

---

I thought the class designer allowed you to visually create the basic structure of your business layer and then have the code generated? I haven't actually used it yet, but AFAIK there isn't anything in it that generates DB access code. As for Visio, AFAIK that's just a drawing program - does it that generate any code?

My idea is to use XML configuration files (like most other mappers) that would describe the mapping between your datasources and your business objects. I want to create a tool that doesn't require the user to derive their business classes from a specific base class (or interface) provided by the tool. The tool would use code generation to create efficient customized code. Um, support for nullable types, can generate the SQL for you or use stored procedures/custom SQL you provide. All the standard mapping features of a good mapper: support for class heirarchies, all types of relationships, conversons between database types and the types used in your business classes, generics, etc. I also want it to have a copy-on-write feature where business classes that are requested are cached so that when they are requested later the same object reference is returned, but when they change the data in the object a copy of the object will be created for use by just that user. All other users requesting that object will get a reference to the original. It will be optimistic concurrency without any round trips to the datasource.

I have seen a "feature" on mappers that use reflection is that they require an extra step for code generation. I don't see how that's helpful? Remember C++ templates when you could fenagle them to run a recursive algorithm during build-time so the answer was constant during run-time? You have all the time in the world during build in an effort to make run-time faster. And code generation creates highly specialized code. What are your thoughts on code generation? Oh, and my mapper wouldn't require special areas in code where you can customize the generated code that won't be overwritten if you regenerate.

I'm making a seperate post for the overall implementation.

The generated code would basically be a huge wrapper around your existing domain layer. It would use the same class names that you created, but would be in a different namespace. You would only use the generated classes in your other software layers, such as the application or GUI layers. If another class library is using your business objects, you've obviously built that class library and if you want to use the mapper you'll need to modify that class library. That modification is actually simpler than it sounds - all you do is change the namespace for the business objects as the class names and interfaces won't be changed during code generation.

The generated wrapper would allow changes in the business objects to be tracked and automatically marked for update so if the user doesn't want to, they don't need to track every object they may have changed. This allows a single method to be called in order to save all changes to the datasource. Of course, there would also be a unit of work class so the user can easily track specific changes.

There's one situation where I'm not sure if the mapper could succeed. Let me explain. Suppose the domain contains these classes:

Code:

---

public class ClassA
{
    private ClassB _b;

    public ClassB B
    {
        get { return _b; }
        set
        {
            if (_b != value)
            {
                _b = value;
                _b.A = this;
            }
        }
    }
}

public class ClassB
{
    private ClassA _a;

    public ClassA A
    {
        get { return _a; }
        set
        {
            if (_a != value)
            {
                _a = value;
                _a.B = this;
            }
    }
}

---

How would any mapper (besides one that generates your domain classes for you and requires a specific base class which we're trying to avoid here) know that the property of say ClassA was changed when the property of ClassB was set? My idea allows you to know when the property of ClassB is set, but it can't know that setting that property also changes the value of the property in ClassA. So far my solutions to this dilema is to force the user to just register their ClassA object as also having changed, or putting an option in the XML configuration file that would allow the user to specify whenever the property on ClassB is set ClassA needs to be marked as changed. Any other ways around this?

Any other problems you see with my idea? I realize someone is probably adverse to generating an entirely new domain layer with all those classes and methods duplicated, but I should point out that it's the mapper's job to generate all that exactly. And also I think an extra level of indirection through a method call is not too high a price to pay, although I realize others may think, well, otherwise. Tell me what you all think!

I am still interested in the concept, but not yet convinced of its worth.

What advantage(s) does this have over routing data-source interaction from business objects through a DAL in the usual fashion? What do you gain by shifting class-specific mapping from individual classes to a centralised source?

Is this basically a way of automating the creation of database interfacing code?

It is a way of automating the creation of the DAL. Using a mapper removes all the database handling code from your business layer and it allows you to generate a perfect DAL instead of writing and testing a new one each project (or at least the new portions - don't tell me you're DAL is plug and play for every single project). Plus I'm sure it will be faster than using typed datasets and dataadapters.