|
Demo Version
|
|
|---|
Download and try for yourself a fully working demo version, including sample apps and documentation. The only limitation is that the demo version only works inside the debugger.
|
|
Subscribe
|
|
|---|
Get It All for $50 USD:
WebPortal, ORMapper,
Source Code, All Updates
|
|
User Login
|
|
|---|
|
|
|
|
Wilson ORMapper Forums : Chat & Share : Advice on presentation
|
|
|---|
| 7/21/2005 10:23:02 AM |
Paul - I have been a big fan of your mapper for a while now, and use it whenever I can (and where it makes sense, of course - which turns out to be most of the time!). I am going to be giving a 1.5 - 2 hour presentation on O/R mapping to the other consultants I work with and was wondering if you wouldn't mind posting your opinion on a rough outline. The guys I am presenting to are coming from your typical ADO.NET background, DataSets, stored procedures, etc. Anything you think would be key points for such a discussion? I am going to try to avoid, as much as possible, the DataSets vs. custom objects discussion and focus more on what O/R mapping is and how it can be used. Any advice you can give would be appreciated. Thanks! |
| 7/26/2005 12:05:01 PM |
What I did recently was that I spent a little bit of time first of all getting the people in my audience to tell me why the standard layered approach was good -- what were they trying to achieve? The answers are usually things like maintainability, encapsulation, loose coupling, flexibility, reusability, performance, scalability, portability, understandable, and specialization. Starting this way gets them involved -- they have just given you the very bullet list that O/RM does better in most cases -- certainly some things are debatable and/or depends on the situation, but many are no-brainers. OK, so what do I do with this list? I drill down into how the traditional approach achieves CRUD, again getting them to help feel in the details -- and then I look at how few of their own goals they have actually achieved! There is lots of repetitive code, persistence code and schema facts are all over the place, there are brittle boundaries that can fail if only one place gets updated, limited filter/sort and paging abilities, little opportunity for reuse, performance optimizations are all manual, connections can (and do) get left open, there is no portability usually, and the business value isn't clear do to all the plumbing code. Once they can agree they really want more, but have failed to achieve it, then I present the way O/RM works and how it does accomplish these (at least in most cases). Only when I've got them to this point do I worry about a few definitions and theoretical rationales (object-relational impedance mismatch = yuck -- until you get them to see it for themselves). Then you can go over the basic features using real examples, discuss issues/myths, and when not to use O/RM. BTW, I've got a Powerpoint you can use/copy if you email me for it -- but most of it is really active discussion which isn't at all clear from the slides themselves.
Thanks, Paul Wilson |
|
|