As I've got tooth ache and can't sleep, I might as well kill some
time...
Negative points:
1) Cost. I'm not sure what it costs, but factor in support, upgrades,
initial purchase and you may be able to get a whole developer for the
money. They could own the development of these tiers and respond
immediately to changing requirements.
2) Transparency. One of the slides in the white paper shows a table
representing an invoice detail line with the name Invoice1. In other
products I've seen generically named stored procedures generated, ie
sp00000001 and similar.
3) Custom script language. Attributes are created using a custom
bastardization of c# and VB with a bit of pootang thrown in. E.g.
error(ExceptionName, "Exception message)
if InvoiceDate > System.DateTime.Now;
I wouldn't want to learn that additional syntax.
4) Appears to require a recompile if you change a business rule. There
are better ways imo which mean you can do it via a database. I can't
confirm that without playing with it, but as it seems to be done at
the dataset level it appears to be accurate.
5) The high level documentation appears to suggest they're
compensating for the developers' ability rather than accelerating
development. I make that assumption purely based on documentation that
is probably aimed at less technical decision makers. They probably
shouldn't be making this decision.
6) I would put money on you spending lots of time creating work
arounds where a specific scenario has not been catered for. This is
frustrating and time consuming. It also means you may learn to think
in terms of the framework rather than in terms of what works best.
7) I'd not heard of it, I don't want it on my CV.
8) I couldn't tell if it supported specific code conventions or not.
It looked like not. Do you want to adopt their conventions or retain
that control in house? I didn't like their conventions and found some
of the whitepapers' shoddy.
9) How had is it to write Select InvoiceID, stuff from Invoice inner
join InvoiceLine on Invoice.InvoiceId = InvoiceLine.InvoiceID? I don't
need a tool for that, I can pop it in a documented SP that includes
comments in about 20 seconds.
10) They claim you don't need to know SQL to use their tools. I can't
say I want to work on a system that uses a SQL database where the
developers don't understand SQL. Again, I've used (and use
unfortunately) tools that try and abstract the underlying access to
the database in a user friendly way. The reality is you spend lots of
time working around limitations, bugs and you need a grasp of SQL
generally over and above what you'd get by with if you didn't have to
make these decisions.
I can cite examples. Business Objects. I actually loved it when I
worked with it, but can you give me a solution to a chasm trap? Cadis.
Hate it with a passion. -- comments cause random bizarre errors like
"select field from table where field is not null" returning all nulls.
11) If you find a bug, how long before you can get it fixed? You may
end up having to manually hand fix autogenerated errors each build
until they get a patch to you.
12) Bloat. Look at some of the screenshots, it's all bloat, a
datareader and dataset for each table, then more for specific business
cases, i.e. what would traditionally be generated based on a view or
sp that serves a specific business need. Can you remove the
unnecessary ones? Do you have the time?
13) unlucky, moving on.
14) Once all this boiler plater is generated, are you good enough to
use it? A rude question I admit, but a sensible one. Lets go back to
the VB6 days; if you lived through that, you'd appreciate the false
sense of confidence a blank form you can drag buttons onto gave
interview candidates. People get upset with VB6, but it's the C# of
the previous generation. High level, easy to use and very powerful
once you get to the Curland level with a bit of Appleman for spice
Ok, there are huge differences, I don't want a big argument, but from
simple practical experience, I find it simpler to pick out an MFC
fraud than a C# fraud, I'm practically one myself so you'd think I'd
know...
15) Their forum was a bit of a mess. A fair few angry people, and a
number of questions that could be phrased as "In your auto-generated
code how do I work around this restriction?". I know I've been there
before, but I think it's a serious issue. Still, nice they had one,
always appreciated.
16) Support for WSE, but none for things like IBM MQ, Tibco as far as
I could tell. That could be an issue. I've only really used MQ under
DotNet, Tibco in other languages, so I may misunderstand how it's
integrated. This raises another issue though. It's possible I could
use MQ by implementing a provider and then telling their framework
about it, but I don't get that impression. That might sound daft, but
I don't feel it's got corporate developers at the heart of its vision.
