IdeaBlade stories?

[sdurity]

My company is looking at the IdeaBlade RAD/ORM tool (www.ideablade.com)
as an aid to building a relatively simple database application (one
main developer, me). I have found the ADO.Net and databinding
"plumbing" to be too demanding of time and expertise to build well. A
business application framework seems to be the best answer. I like what
I have seen in the tool. IdeaBlade's references (of course) are quite
happy with the tool. I wondered if anyone had failures with this tool
or decided against it for any particular reason. We would like to hear
all sides of the story.

Sean

(P.S. I really don't have time to investigate every framework out
there. I don't really need pointers to other options, yet. I'm
interested in what others use, but just pointing me at nHibernate, et
al, isn't useful for me now.)

 

[Andy]

Sean,

The easiest thing to do would be to implement something like this:
http://www.codeguru.com/columns/DotNet/article.php/c6599/

Basically you define a base class and some custom attributes. Then you
create a class which inherits from this base, and marks properties as
'DatabaseField's. You could would at a minimum look like the table it
represents and the base class would provide load, save and delete
functionality. there are alot of different things you could do
building such a framework, but you could build one to suit your needs.
Once the framework is in place, you could also build a program that
examines a database table and generates the class for you (ie, it would
inherit from the proper base class, and create properties for each
field and make the properties as a database field).

I've done this, and it works very well. With a good design, you could
even allow for different database systems; in my case, a base Entity
provides much of the functionality (using reflection to build a list of
the columns, for example) and then I have a SqlEntity which 'knows' how
to talk to Sql Server, Filemakerentity knows how to talk to Filemaker,
etc.

When i need to access a new table, I have a tool i created which allows
me to point to the table i want, and generate the approriate class.

In your business layer, the plumbing code is simply creating the class
which represents the table, telling it to load and then copying the
values from its properties into your business object.

HTH,
Andy

 

[Mike]

Sean,

The easiest thing to do would be to implement something like this:
http://www.codeguru.com/columns/DotNet/article.php/c6599/

Basically you define a base class and some custom attributes. Then you
create a class which inherits from this base, and marks properties as

Or, if IdeaBlade does the job and you can afford it, don't re-invent the
wheel...

If one part of IdeaBlade is the most attractive to you - the O/R mapper, for
instance, there are a dozen or so choices in this area that can generate
classes from an existing DB, or generate a DB from classes, or generate both
from XML, or go all ways from Sunday - it really depends on what you have to
start with and where you want to end up. (Is there an existing legacy DB
and/or existing business objects? ...?)

There is of course, no shortage of cool data-bound controls for .net as
well, so coding may be minimal.

But sometimes (close to) no coding is great if the tool does what you're
after...

Seems to me though that if you auto-magically generate a DB app., it should
be web-based, and not a rich client -- though I'm not exactly sure why I
feel that way at the moment. Also, code-generation, which tends to be a
one-way street, is not great IMHO - I'd prefer a framework that did as much
as possible at runtime using metadata than up-front using spewed code - you
can probably find both approaches out there.

m

 

[sdurity]

Or, if IdeaBlade does the job and you can afford it, don't re-invent the
wheel...

Exactly. My time is worth more than the upfront cost. I am not just a
developer. I have IT Mgmt responsibilities, too. If a tool can help me
build applications faster, then it is a plus. We don't sell software,
so there is no real competitive edge to building our own framework. In
fact, it might be a hindrance if I were ever to leave.

I got a few answers more directly from users on the ideablade
newsgroups. So far the feedback is very positive. One company chose a
different tool, b/c they wanted industrial strength ORM and not the UI
binding part.

I hope a few more folks respond here.

 

[Andy]

<i>Or, if IdeaBlade does the job and you can afford it, don't re-invent
the
wheel... </i>

Its been my experience that out of the box OR mappers handle simple
cases very well, but fail for more advanced data needs. Why have an
elaborate framework to do what usually amounts to:

this.X = data.x;
this.Y = data.y;

<i>Seems to me though that if you auto-magically generate a DB app., it
should
be web-based, and not a rich client -- though I'm not exactly sure why
I
feel that way at the moment.</i>

If you're building a proper n-tier application (which it sounds like
Sean is) your UI shouldn't really matter all that much. In fact
there's no reason he couldn't have multiple UIs built off the exact
same business objects.

<i>Also, code-generation, which tends to be a
one-way street, is not great IMHO - I'd prefer a framework that did as
much
as possible at runtime using metadata than up-front using spewed code -
you
can probably find both approaches out there.</i>

Code generation saves quite a bit of time. Again, when done properly,
any changes simply require a regeneration. But I only recommended that
to get started. Why type the code for 10-20 properties (fields) every
time you need to access a new table? Once you generated the data class
though, its pretty easy to make changes and keep things in sync.

Doing everything at run time is great if performance isn't a concern at
all.. but I think there's also something to be said for being able to
do a compile to find errors instead of having to run it. There are
more interesting problems than tracking down typos.

 

[Mike]

<i>Or, if IdeaBlade does the job and you can afford it, don't re-invent
the
wheel... </i>

Its been my experience that out of the box OR mappers handle simple
cases very well, but fail for more advanced data needs. Why have an
elaborate framework to do what usually amounts to:

this.X = data.x;
this.Y = data.y;

Well, you say that OR mappers handle simple cases well, and then say that
most cases are simples cases -- so, ergo, OR mappers handle most cases
well...

Anyway - I disagree. OR mappers can handle very complex cases - including
multiple methodologies (even in a single transaction) for storing full
object graphs in relational form, spanning tables and databases, using views
rather that hard tables, supporting both dynamic SQL and stored procs for
acessors/setters, various object caching options for each class, etc.

<i>Seems to me though that if you auto-magically generate a DB app., it
should
be web-based, and not a rich client -- though I'm not exactly sure why
I
feel that way at the moment.</i>

If you're building a proper n-tier application (which it sounds like
Sean is) your UI shouldn't really matter all that much. In fact
there's no reason he couldn't have multiple UIs built off the exact
same business objects.
Sure.

<i>Also, code-generation, which tends to be a
one-way street, is not great IMHO - I'd prefer a framework that did as
much
as possible at runtime using metadata than up-front using spewed code -
you
can probably find both approaches out there.</i>

Code generation saves quite a bit of time. Again, when done properly,
any changes simply require a regeneration. But I only recommended that
to get started. Why type the code for 10-20 properties (fields) every
time you need to access a new table? Once you generated the data class
though, its pretty easy to make changes and keep things in sync.

Doing everything at run time is great if performance isn't a concern at
all.. but I think there's also something to be said for being able to
do a compile to find errors instead of having to run it. There are
more interesting problems than tracking down typos.

The ability to handle errors is the same whether code is compiled, or other
meta-data is verified against the schema and classes.
I don't see where "typos" come in - I'm still talking about a fully
automated process.
As far as performance, of course every situation is different - but I'd
wager that for 90% of applications (non-tremendous dataset, managable # of
simul. users, etc.), this descision will have no human-measureable
performance penality - especailly sense the OP asked about a "relatively
simple database application" -- and taking advantage of an O/R mapper's
object cache can significantly speed up a demanding application that hits
the DB every time.

m

 

[Frans Bouma [C# MVP]]

<i>Or, if IdeaBlade does the job and you can afford it, don't
re-invent the
wheel... </i>

Its been my experience that out of the box OR mappers handle simple
cases very well, but fail for more advanced data needs. Why have an
elaborate framework to do what usually amounts to:

this.X = data.x;
this.Y = data.y;

that's not advanced. Advanced O/R mapping is more focussed towards
pulling graphs of objects out of the DB in an efficient way and saving
/updating graphs of objects with a single line of code (so all objects
are saved in the right order, FK's are synced with PK's automatically
etc. etc.).

That takes a lot of work to get it right. reading a table and storing
values into a class' properties isn't hard. (although renaming fields
on the table or entity side, re-ordering them on the table or entity
side often cause trouble for some o/r mappers )

<i>Also, code-generation, which tends to be a
one-way street, is not great IMHO - I'd prefer a framework that did as
much
as possible at runtime using metadata than up-front using spewed code
- you
can probably find both approaches out there.</i>

Code generation saves quite a bit of time. Again, when done properly,
any changes simply require a regeneration. But I only recommended
that to get started. Why type the code for 10-20 properties (fields)
every time you need to access a new table? Once you generated the
data class though, its pretty easy to make changes and keep things in
sync.

I hope you don't refer to the process of keeping mappings in sync with
a db schema as 'easy'

Doing everything at run time is great if performance isn't a concern
at all.. but I think there's also something to be said for being able
to do a compile to find errors instead of having to run it. There are
more interesting problems than tracking down typos.

Exactly. That's also why an O/R mapper should have a fully OO query
language/mechanism, not string based stuff: the second you rename a
field in your entity, it might break queries everywhere, but without
compiletime tracking, it's hard to find these at compile time.

Frans

--