Dave Burke : Freelance .NET Web Developer specializing in Online Communities

Wilson ORMapper

When Tim Haines mentions that a new version of the Wilson ORMapper is worthy of my attention, I listen.  Of course I already knew about Paul's ORMapper and his other great products, but now that I'm thinking a lot about smart client architecture, it was time to spend some quality time with Wilson ORMapper.

If you haven't spent time with a mapper, Wilson ORMapper will give you a great introduction in no time.  Included in the free download .zip are two quick demo projects and an example project with full source.

After working with the demo and example projects I spent time in Paul's forums area where any remaining questions were already answered by Paul, who obviously spends a LOT of time and effort supporting users of his products. 

Another interesting aspect of Wilson ORMapper is how it creates mappings and classes using CodeSmith.  Yes, the .cst's are included in the download, but they work in sync with the .exe.  So it’s not like you can open them in CodeSmith and create your own classes from the templates, but they are interesting CodeSmith templates that demonstrate some good tips in code generation.

As for the mapper and me, I plan to explore it further, but in a web services/disconnected architecture (without building my own provider) a mapper doesn't seem the best choice for now. I hope I find a good reason to use it in my environment, since Paul Wilson is definitely one of the very best developers out there.  Wowsville, baby!

 

Comments (7) | Post RSS RSS comment feed

Posted on 6/1/2005 12:53:00 PM by Dave Burke
Categories: .NET
Tags:

Related posts

Comments (7) -

6/2/2005 5:21:54 AM Permalink

Hey Dave:

Actually the CodeSmith templates are just standard templates that have no connection to the WilsonORHelper.exe.  Think of these as two possible alternatives to get started -- you can use the ugly GUI ORHelper that I wrote, or you can use the far better CodeSmith templates that Paul Welter contributes.  And of course even if you don't like some of the things in the templates you can change them yourself, unlike the ORHelper which is what is and no more.

Also, you can use most O/R mappers, including mine, with web services, remoting, or other distributed architectures.  The difficulty, if you consider it one at all, is that you still need to create all the plumbing for that architecture, just as you would if you weren't using an O/R Mapper.  To me that's the same work that you would have done anyhow, so I personally consider it a non-issue, but you may feel differently of course.  By the way, as far as I know, EntityBroker is the only .NET O/R Mapper that has built-in support for remoting, although I don't know how it handles web services.

Thanks, Paul

Paul Wilson |

6/2/2005 5:35:40 AM Permalink

Hey, the GUI ORHelper isn't ugly!  It works just fine!  As for the templates, I was getting "Path must be a valid file" and other exceptions when executing in CodeSmith and there was no database or table(s) selection option.  I'll look into them more now that you've described what role they play.

Yes, I read what you told someone else on your forums about creating the plumbing for a disconnected architecture and I'm trying to get my head around that.  Looking at your great sample code, I assume I start with adding an override to creating the ObjectSpace to include a mappingFile location as well as, say, the location of a client-side Dataset?

Global.Manager = new ObjectSpace(mappingFile, connectString, Provider.Access);

I'll think on this more, cause like I said, as I would really like the opportunity to use your mapper.  Keep up the excellent work, Paul!

daveburke |

6/2/2005 7:10:12 AM Permalink

There's probably more than one way to do it, but my concept would be that your server process would totally own the ObjectSpace and the clients would be totally ignorant of it.  The server would simply expose methods that the clients could call to get serialized objects based on certain conditions that you define.  Similarly the server would expose methods that the clients call to pass objects back to be persisted -- that might be a serialized object, but it could also be a list of members that the server uses to reconstruct the object.  Its typically a lot easier to work with serialized objects than datasets, especially if you may have some non-.net clients, but of course you have to be careful.  You also have some tough decisions since you can't use lazy-loading in a disconnected scenario -- that means you either have to include relationships all the time, or you have to not use automatic relationships.  Which way is best is typically a tradeoff between how your data is to be used and how you can optimize things -- and there is no easy answer since its situational -- which in the end brings you back to the fact that distributed systems are not "hard" but there are a lot of choices.

Paul Wilson |

6/2/2005 7:17:28 AM Permalink

I will definitely think about your architectural suggestion and the design aspects you described.  You are absolutely correct about the tough decisions in designing a distributed app.  My thinking-to-typing ratio is much higher than normal and I will be happy when the decisions are made so I can get back to more typing and less thinking.

daveburke |

6/6/2005 9:04:11 PM Permalink

Dave,

I spent a lot of time working on the abstraction that allows Base4.NET to work in a client/server environment. Out of the box it supports Remoting, but you could reconfigure it to use SOAP or REST easily enough. I agree with Paul about making it so the Server total owns the ObjectSpace, that is what I do. I would say this, it is not a simple thing to put this on top of your existing O/R mapper, there is a lot involved, especially if you want to do lazyloading, which contrary to what Pauls seems to be saying is quite possible since on the clientside the only real change is that your Objectspace is a Proxy only. Supporting Lazyloading in a client/server environment makes ObjectScoping much more important for performance reasons.

Some words of warning before you head down this path:
1) watch out for Type Serialization problems.
2) be careful if the server has a bigger view of the ObjectSpace than the client, you don't want to accidently ship and object to the client that the client knows nothing about!
3) often you will need to provide type resolvers to help the default .NET deserializers

Now a word of warning Base4.NET is not as powerful an O/R mapper as something like Paul's one. It has a different focus altogether, it's vision is to be an Extensible Database File System. As a result I hesitated before posting this comment, I don't want you to think it is an O/R mapper. However if you are looking for some ideas/sample code to show how to proxy an ObjectSpace remotely Base4 does solve most of those problems and is open source, so you could re-apply to a real O/R Mapper like Paul's.

Hope this helps
Alex

Alex James |

6/6/2005 9:10:26 PM Permalink

Alex, I appreciate your insights very much.  I've already encountered type problems (null values), which I've handled with default values in the mapping.config.  

Ownership on the server side.  Thanks for the reminder!  And with the client Objectspace serving proxy duties only.  I must think more about that.

Base4.NET.  I didn't know about that, but to better grasp these concepts your recommendation is a good one.  I will definitely try to investigate Base4.NET at my earliest convenience.  

Thanks again for your time and insight here, Alex.

daveburke |

6/6/2005 10:54:55 PM Permalink

No worries at all Dave, it's my pleasure.
Let me know if you need any help working out which bits of the code are relevant, Alex at base4 dot net

Alex James |


Powered by BlogEngine.NET 2.0.0.36
Theme by Dave Burke