Pondering UI Mappers...

I've done a bit of reading over the last couple days.  DonXML mentioned Domain Driven Design (DDD) in a comment.  This led me to a series of posts from Steve Eichert on DDD.  This post of Steve's was very intriguing to me.  He talks about the need for UI Mappers and how they could potentially make life easier. 

Now you all know that I am not a fan of OR mappers.  Actually that's not totally true.  My issue is really with some of the dynamic ones that build their own dynamic SQL, etc.  Sorry, I guess I'm a control freak... I want to know that the SQL being generated is my SQL and not someone else's.  I also don't like code generation that is not my own code... I want to be able to understand every line of code, and be able to justify it if someone questions me on it... Which means that I use CodeSmith to generate my data access layer... I'm basically doing OR mapping with my templates.

So a UI Mapper maps entity objects to your UI objects.  All that code where you say "tbAddress.Text = entity_obj.address;" could be built in a more dynamic manner. 

So I downloaded Paul Willson's UI Mapper.  One thing I can see with Paul's products are that they are flexible, so Wilson's UI Mapper doesn't require you to use his OR Mapper... From what I have read (nope I haven't used it yet) Wilson's UI Mapper uses an XML file to do the mapping (my bet is that you have a number of other ways of doing this too).  It seems cool, but the control freak in me wants something else.

What I want is a CodeSmith Template that can build code.. my code... to do the OR Mapping.  There's a lot to this.  I'm thinking that another layer needs to be build (actually it's sort of the Controller pattern. -- I'm cool... I mentioned a pattern).  The idea is that there would be a new set of classes to go between the UI and the Business Objects (and maybe also the data layer).  Basically you would have a method where you would pass an instance of a form (web or win) and instruct the Controller layer to fill the form with data. 

I will blog later about my ideas for implementing this with CodeSmith...

Print | posted on Wednesday, June 01, 2005 10:49 PM

Feedback

# re: Pondering UI Mappers...

left by at 6/2/2005 12:41 AM Gravatar

I've actually done something like this (though it's perpetually halfway finished ;) ).

The UI/Mapper is pretty spiffy, but it's really more than I need. What I need is something simple that keeps me from having to write a hundred lines of code to shuffle values back & forth between a form and some objects.

So I wrote a UIBroker to do just this. Initially it handled generating Validators, WinForms, WebForms, etc... but it was crap to be honest.

So I rewrote it, focusing on WebForms, and only just what I needed for a project at work. So it does much less now than the old version, but it's cleaner, and a better boiler-plate for expansion now, so I'm happy with it.

To be honest it's not much more than John Dyer's MSDN article www.msdn.net/.../default.aspx in it's current state, but hopefully I'll find the time to improve on it a bit more.

# re: Pondering UI Mappers...

left by at 6/2/2005 5:17 AM Gravatar

"Now you all know that I am not a fan of OR mappers.  Actually that's not totally true.  My issue is really with some of the dynamic ones that build their own dynamic SQL, etc.  Sorry, I guess I'm a control freak... I want to know that the SQL being generated is my SQL and not someone else's."

haha, sorry, but I always have to laugh about those comments. :). You also write the DBMS client? Because how would you otherwise know if the command you crafted is sent efficiently over the wire? And how about grids? You write your own grids as well?

Btw, you DO control the SQL being generated: through the O/R mapper command you're using and the parameters (filters, query meta-data) you're passing in.

"I also don't like code generation that is not my own code... I want to be able to understand every line of code, and be able to justify it if someone questions me on it... Which means that I use CodeSmith to generate my data access layer... I'm basically doing OR mapping with my templates."

So, you write your guis in windows forms by hand too?

You're really out of touch with reality. ;). The term for this is NIH-syndrome. "Not Invented Here"-syndrome in full. And you have it, suffer from it, and your clients/customers suffer from it too. The problem with people suffering from NIH-syndrome is that they take a lot of time writing code which can be created much faster by tools if they hadn't been so paranoia.

Oh, and O/R mapping with codesmith templates isn't possible. You can generate code and all that, but the real benefits of an O/R mapper engine are in the dynamic SQL engine and in recursive graph handling, etc. etc., something which is hard to write for yourself. Make no mistake, writing an O/R mapper is very hard and a lot of work, 10 to 1 your 'templates' are just scratching the surface (and probably utilize good ol' stored procedures too, because they're compiled and faster, right? ;)) of what's possible.

But it's your loss. Seriously, it is. There is nothing wrong with understanding the code you're using, though that's something else than saying "I only trust my own code".

Because I can assure you, people who write O/R mappers for a living, and I'm one of them, know everything about them and know what you can and can't do. They're specialists in that specialistic field. If you think you can do BETTER, go ahead, but I doubt you will. That might sound arrogant (probably), but it has to be said. Software developers should focus on the field they're good at and utilize the fine work of others for the fields they're not good at. That's why developers buy controls, buy O/R mappers and buy databases, because writing these all by hand is undoable.

You use Codesmith for a code generator. You didn't write your own code generator engine, while the whole template parsing/code generation engine is just 200-300 lines. It's perhaps the first step to get fully cured. :)

# re: Pondering UI Mappers...

left by at 6/2/2005 6:41 AM Gravatar

Try MyGeneration:

www.mygenerationsoftware.com

With it's OR mapping:

dOOdads

It has open source code.

And you can also alter the template which does it al.

there is also a very open DAL generator at eggheadcafe for Access / MS Sql.

# re: Pondering UI Mappers...

left by at 6/2/2005 9:42 AM Gravatar

We use a framework that uses Attributes for our UI mapping.  We build our controls, our business objects, and use Web Service calls to get our data.  Once everything is set up you can drag one of my controls onto your form, place an attribute above the control which tells it how to map to the business object, hit F5, the form will come up with the control fully populated with data.  Also has built in validation and conversion.

# re: Pondering UI Mappers...

left by at 6/2/2005 2:01 PM Gravatar

Paul Wilson has written one, you can get it over at his site. There was a lively conversation going on at his site, with a little bit at mine, about UI mappers a while ago.

www.lazycoder.com/.../auiml-by-ibm-alphaworks

weblogs.asp.net/.../179588.aspx

BTW, DDD is a great book. I agree with DonXML , the GOF patterns book is a little dense, but I think it's a little like Times Square. If you're gonna go to NYC, you gotta go see Times Square at least once.

# re: Pondering UI Mappers...

left by at 6/2/2005 3:05 PM Gravatar

I was kind of hoping that someone would come to my rescue so that I didn't have to sharply disagree.

Frans Bouma (I believe he is the author of LLBLGen Pro) responded to my thoughts on OR Mappers sharply.  (actually he responded rather arrogantly IMO).  Note: I have never used Frans ' product and I probably never will.

Let's take a snippet of his text and respond...

"Oh, and O/R mapping with codesmith templates isn't possible. You can generate code and all that, but the real benefits of an O/R mapper engine are in the dynamic SQL engine and in recursive graph handling, etc. etc., something which is hard to write for yourself. Make no mistake, writing an O/R mapper is very hard and a lot of work, 10 to 1 your 'templates' are just scratching the surface (and probably utilize good ol' stored procedures too, because they're compiled and faster, right? ;)) of what's possible. "

Yeah, you got me... I don't use dynamic SQL... I prefer the easy route to security and tuning (especiailly considering in my big corporation someone else maintains the servers... tracking down issues where someone changed a permission is painful).  I prefer to decide up front what types of querying I'm going to allow on my system, and build stored procs accordingly.  Mainly, because it's easier to build indexes and tune the SQL from a stored proc versus tuning against queries in the query cache.  I'm not saying his way is impossible... it's just not the way most DBAs prefer to work.  I then generate code based on my stored procs.

BTW, I know that I said "I only trust my SQL code," I meant the second part to be the major point: I want to make sure that I understand the code and can defend it...  I regularly use other people's libraries and own commercial software development tools, but usually for those tasks that are a little out of my realm or are a little more specialized.

Another quote:

"Because I can assure you, people who write O/R mappers for a living, and I'm one of them, know everything about them and know what you can and can't do. They're specialists in that specialistic field. If you think you can do BETTER, go ahead, but I doubt you will. That might sound arrogant (probably), but it has to be said. Software developers should focus on the field they're good at and utilize the fine work of others for the fields they're not good at. That's why developers buy controls, buy O/R mappers and buy databases, because writing these all by hand is undoable. "

I guess I'm not sure that the all that "flexibility" is necessary in every app (and when it is it doesn't normally extend to the entire system.  Besides writing SQL for me is easy (I've been doing database design/programming for 12 years -- 9 of which have been with SQL Server, 6 with Oracle, and 3 with PostgreSQL)...

Sorry , Frans (and all my readers who are O/R Mapper fans) I feel that O/R Mapping coddles the weak... (or at least it might coddle the weak)

(I know I'm going to get flamed... it's just my opinion)

# re: Pondering UI Mappers...

left by at 6/2/2005 5:35 PM Gravatar

While I personally prefer a good O/R Mapper and/or UI Mapper to Code Gen, I've also always tried to say that I think Code Gen can be a viable option.  The problems I have with Code Gen are that I haven't seen anyone personally use it well in the long term -- and its the long term where the maintenance issues can get out of hand.  But I think if you have a solid Code Gen process then it can be a viable alternative -- and even if you lack the process that's not to say that you can't get a great start pretty quickly and hope its good enough to avoid the long term issues.

# re: Pondering UI Mappers...

left by at 6/2/2005 6:19 PM Gravatar

"I feel that O/R Mapping coddles the weak.."

Dang man, now I'm weak? Guess you're over the trusting me thing huh? ;) I wrote an EXTREMELY SIMPLISTIC O-R Mapper for quick prototyping, but no one knows about it or uses it. I don't use Frans's mapper, but I've used Gentle.NET on a couple of projects.

Sorry I can't defend you, I agree with Frans on most of his points. In my mind, writing your own CRUD procedures is a form of self punishment. Martyrism at it's finest. Get out the hairshirt, ashes, and whip.

Case in point, today we had to add a column to a table in the database. This requied me hand editing multiple sprocs and 3 C# classes. Since  I touched all that code, I have to regression test all of it. Since the most robust editing environment that I'm aware of for SQL server sprocs is Query Analyzer, I caught a couple of bugs that only a regression test could catch since I switched the order in my Columns and Values list, meaning that the data meant for  one column was inserted into another. All of that regression testing of the sprocs, code, UI, etc... means longer wait times between releases for my users. Since my users sit across the hall from me now, it means more sighs and "When will you be done testing?" questions when I see them.

The biggest problem I see with using any third-party tool, and this isn't related to NIH syndrome, is it's one more dependancy you have to track. One more thing you have to maintain if it ever falls out of support or is abandoned. I've dealt with some pretty high-throughput applications and I haven't seen an instance where the performance benefits of sprocs over dynamic sql have been worth the trade off in flexibility. IMO if you want to increase the performance of your application, first look to minimize the number of times you have to access the file system (especially DB hits) before you start worrying about whether or not the execution plan is pre-established.

# re: Pondering UI Mappers...

left by at 6/2/2005 6:34 PM Gravatar

Scott,

I think I was set off by the attitude more than anything.  I understand what you are saying...

I guess I've been indoctrinated by too many DBAs... <grin />

BTW, the point was just me firing back (probably back harder than I should have) over the whole NIH statement...  Sorry if I offended anyone but Frans... and actually you don't need to be offended either Frans...

I read your comment on the other post... I like you... I might check your product out...

# re: Pondering UI Mappers...

left by at 6/2/2005 7:04 PM Gravatar

Yah, not that Frans needs defending. But he's a good guy, he knows his stuff from what I've seen.

Just be glad Thomas T. didn't wander into here. blech.

# re: Pondering UI Mappers...

left by at 6/2/2005 9:51 PM Gravatar

Paul,

Somehow I missed your comment in the whole stir I accidently created (I really wanted to talk about UI mappers)...

Thanks for the benefit of the doubt... I really didn't set out to dump on O/R Mappers; I really didn't.

# re: Pondering UI Mappers...

left by at 6/3/2005 2:22 PM Gravatar

"I have never used Frans ' product and I probably never will."

And that's your loss. Frans has an awesome product. I don't personally care much for the API, but LLBLGenPro has a level of polish I don't think I've seen in anyone else's product.

"I prefer the easy route to security and tuning"

Tuning with Profiling/Traces is a lot more "right" than just messing with a sproc until you find something that works IMO.

And the security argument is laughable. Seriously. You're smarter than that. No one ever said that if you did need to hide a process from your AppDomain you couldn't use StoredProcedures to do so, but those types of operations are only a small fraction of an application's data access needs.

"Sorry , Frans (and all my readers who are O/R Mapper fans) I feel that O/R Mapping coddles the weak... (or at least it might coddle the weak)"

You're entitled to your opinion.

I think viewing a database as anything but a glorified persistence mechanism is narrow minded. That picture is that no one cares about your data if they can't fiddle with it in an environment that's simple, comfortable, fast, etc.

While you can have sprocs & code-gen, I can swap out my entire persistence in a few lines of code. I can add second-level caches, move the application across the country, or the world, and I can deliver real value to the end users faster, with higher performance, more securely.

# re: Pondering UI Mappers...

left by at 6/30/2005 1:01 AM Gravatar

Jay,

Listen to Frans. It's good for you. I know I listen to him.

- SM

Title  
Name
Email (never displayed)
Url
Comments   
Please add 4 and 6 and type the answer here: