Hi All,

I've been doing some research for a few days now into what OR Mapper/code gen app to go with for the company I work for.

I have been trying LLBLGenPro and really like some of the features it offers. Our current DB design uses some entity inheritence (mainly a base table that contains auditing info - 1:1 relationship) and I like the fact that LLBLGenPro handles that properly. I realise it's more specifically an OR mapper than a code gen tool am I right?

I am impressed with CodeSmith and the .netTiers templates so far. I've downloaded the trial and generated Northwind example code complete with a web app & user controls to use as an admin for the entities. I think the fact that .netTiers uses the MS Enterprise Library is good too.

I have read the lengthy discussion over at Frans' blog re Dynamic SQL vs Stored Procs and the ensuing debate. I was thinking of ditching stored procs altogether to reduce maintenance but with the stored proc code generation by .netTiers, that may change my mind.

Without launching into a full blown flame war, can I have some opinions from the LLBLGenPro community as to why LLBLGenPro is a better option than CodeSmith w/.netTiers in OUR CASE? Any stories of you guys going with one over the other then regretting it?

Many thanks, Luke.

Everything codesmith can do, you can do with llblgenpro as well. On top of that, LLBLGenPro comes with a very rich O/R mapper core + templates which results in a rich Data access layer and business components. LLBLGenPro doesn't generate everything, just specialization code on top of the runtime libraries. This has the advantage that a lot more features are available to you for less code. This is especially useful in larger projects (500+ tables).

LLBLGen Pro is a code generator AND o/r mapper, not just a code generator . It uses code generation to generate code you otherwise had to type in by hand, but the code generator engine is very powerful, in fact, due to its hierarchical structure (execute as much tasks as you like in 1 go), flexible template-system (define tasks independently from templates), it makes it more powerful than other code generators which focus on 1 task and 1 template.

First, let's be clear about what we are comparing and what can be compared.

We have at least 2 primary topics at hand, as follows...

(1) the tool to produce an architecture

(2) the architechture produced by the tool

While it is obvious that the 2 topics are interdependent, it is still essential to make the distinction when discussing the topics, for the sake of clarity.

To that end, I am going to address (2) because I think that (1) is a fuzzy comparison given that the tools, CodeSmith and LLBLGen, are designed to do different things.

The most valuable discussion, IMHO, is to compare...

--the architechture produced with LLBLGen

vs

--the architechture produced with NetTiers

If you know wood working, CodeSmith is like a Saws-All and LLBLGen is like a top-of-the-line compound miter saw with laser attachment. Sure, some of the things that you can do with one, you can also do with the other. But, some other things that you can do with one, you simply cannot do with the other. In short, the functional overlap is more apparent than actual.

That said, I will try to address some of your points; but, note that I am only about 5-months familar with LLBLGen and only about 8 hours familiar with NetTiers.

louieo wrote:

Hi All, I've been doing some research for a few days now into what OR Mapper/code gen app to go with for the company I work for.

I have been trying LLBLGenPro and really like some of the features it offers. Our current DB design uses some entity inheritence (mainly a base table that contains auditing info - 1:1 relationship) and I like the fact that LLBLGenPro handles that properly. I realise it's more specifically an OR mapper than a code gen tool am I right?

Yes. That is right, at least for the current shop where I work, we use the LLBLGen templates out-of-the-box. But, we do use the LLBLGen GUI to make a lot of TypedLists and TypedViews, which (in a way) is a code-generation-style task.

louieo wrote:

Hi All, I am impressed with CodeSmith and the .netTiers templates so far. I've downloaded the trial and generated Northwind example code complete with a web app & user controls to use as an admin for the entities. I think the fact that .netTiers uses the MS Enterprise Library is good too.

Yes, NetTiers CodeSmith Templates are a decent way to go, in some cases. But, I have studied them and LLBLGen and I will say that I am pretty darn sure that the NetTiers CodeSmith templates will not be able to handle or do 100% of the stuff that LLBLGen does. For example, the dynamic query engine in LLBLGen is probably quite a bit more powerful than what NetTiers offers. The EntLib is OK, but, despite how much I want to like it, I am pained when I have to actually do something special with it-- I find it bloated, unclear, cluttered, overly-complex, intrusive, and monlithic. Sure, it works, but I really with they had an EntLib Lite version.

louieo wrote:

I have read the lengthy discussion over at Frans' blog re Dynamic SQL vs Stored Procs and the ensuing debate. I was thinking of ditching stored procs altogether to reduce maintenance but with the stored proc code generation by .netTiers, that may change my mind.

Yes, SPs are, in general, not a wise design decision in most of the cases (except for exceptional cases, such as large bulk-processing, large batch processing, some reporting tasks, and the like). That said, if one must use SPs, IMHO, then specifically and only generate them. Never edit them by hand. I used a code-generation template set on a previous project which did generate 100% of the SPs. I never had to touch the actual SQL code. Those SPs were tightly-coupled to the generated object-layer. It worked and it was easy to maintain. But, I still would have avoided the SPs if I could have simply because having another code base to maintain/ generate/ deploy/ tweak/ secure should be avoided if possible.

louieo wrote:

Hi All, Without launching into a full blown flame war, can I have some opinions from the LLBLGenPro community as to why LLBLGenPro is a better option than CodeSmith w/.netTiers in OUR CASE? Any stories of you guys going with one over the other then regretting it?

Here are some off-the-cuff thoughts.

--Cost-- NetTiers is free. The old, console version of CodeSmith is free. But, free means what? Support might die? Project might die? And so on. LLBLGen costs a little bit but it is a very little bit given what it gives you. Therefore, it is not much of an issue.

--Maturity-- NetTiers, according to http://www.NetTiers.com , is in Beta. LLBLGen is, well, released and the next version is on the way-- very stable and very emergent.

--Licensing-- NetTiers, (given that is a SourceForge project, last I checked), is GPL (or some GPL variant of "open source", whatever the heck that means these days), which, IMHO, is not so good. I use GPL products if I must; but, I try to avoid them. LLBLGen is not GPL.

--Approach-- I generally really like CodeSmith template-driven development. I use it when I can. However, a real good ORMapper, like LLBLGen, makes for an entirely different type of development. I am not sure where I come down on the matter for sure-- for today, I will say I am 50/50. I really like using LLBLGen. I really like using CodeSmith. I will say that with every CodeSmith template set that I have used or written, there is always something that I wish it could do but, due to various constraints, the template set did not support that particular feature but rather presented a workaround. With LLBLGen, I must say, with our medium-large suite of projects here, it has never failed to be able to do exactly what we want it to do.

HTH.

Thank you.

--Mark Kamoski

Thanks guys for the info and thoughts - much appreciated

I do find that the code generated by LLBLGenPro is a bit "lighter" and easier to work with off the bat than the netTiers code. We are leaning towards LLBLGenPro but have one final query.....

One feature of NetTiers we like is the fact that it can take us right through to creating the ASP.NET user controls to use in an admin section for the site (and more so the fact that these are generated, hence updated everytime the DB schema changes). As Frans mentioned that LLBLGenPro can do the same sort of code gen as CodeSmith, can anyone point me in the direction of how I can generate something similar using LLBLGenPro?

Thanks, Luke

You mean for each entity, you want to have ASP.NET controls for edit/insert/delete etc. ?

Thanks Mark for your kind words!

Otis wrote:

You mean for each entity, you want to have ASP.NET controls for edit/insert/delete etc. ?

Yep that's correct - if it's possible to script the generation of a list control for each entity and perhaps a new/edit control

You can do that of course, though there are no public templates which do that for you at the moment. Some customers have written these templates for themselves though, so it is possible.

louieo wrote:

...We are leaning towards LLBLGenPro but have one final query.....

...As Frans mentioned that LLBLGenPro can do the same sort of code gen as CodeSmith, can anyone point me in the direction of how I can generate something similar using LLBLGenPro?...

To use the template creation/management features of LLBLGen, one needs to buy LLBLGen and then download the "LLBLGen TemplateStudio", which is the template IDE for LLBLGen.

HTH.

Thank you.

--Mark Kamoski

Greetings,

We are evaluating both .NetTiers and LLBLGenPro as well. The auto-generated CRUD forms are very nice and relieve us from a lot of tedious work. There are quite a few examples available for CodeSmith about how to do this...would it be too much to ask a LLBLGenPro guru to post an (very simple) sample template so we can get an idea about what's involved to create one of these templates using LLBLGen?

Can these templates be made, "database aware", so, if we add a column to a table and regen we do not have to rework the CRUD template to see the new field on the CRUD form, etc.?

TIA, Rob

rblinton wrote:

Greetings, We are evaluating both .NetTiers and LLBLGenPro as well.

I think that the 2 are not mutually exclusive. We use LLBLGen with the stock Adapter template. Then, when necessary, we use CodeSmith as-needed after that. Sure, you could use one or the other; but, I think that both have stengths and weaknesses. That said, if I had to choose just one or the other, then I would choose LLBLGen because the out-of-the-box templates produce a top-notch architechture and it offers a great template designer.

rblinton wrote:

...The auto-generated CRUD forms are very nice and relieve us from a lot of tedious work. There are quite a few examples available for CodeSmith about how to do this...would it be too much to ask a LLBLGenPro guru to post an (very simple) sample template so we can get an idea about what's involved to create one of these templates using LLBLGen?

I am sorry; but, I am not n LLBLGen guru. I wish that I was. On our team, we simply use the Adapter Templates out-of-the-box for LLBLGen. Making generic CRUD screens doesn't help us because our UI needs to be a bit more sophisticated/customized than simple "list every column for every table" forms. I think that auto-generated CRUD screens "seem" like a good idea. But, I have yet to be on a project where the client said "sure, that's what we want... just plug it in". More is the case that the client says "I want this and that and the other thing" and pretty soon, the CRUD screens are so customized that they cannot be auto-generated. So, yes, for the 1st run of the auto-generation, you save time. But, that's not the bulk of time savings in code generation. One essential point to code-generation is that the code can be generated AND re-generated at will to sync with the current data store. If re-genereration is not possible, then the time-savings goes out the window. IMHO.

All that being said, it should be mentioned clearly...

To write a simplistic template that produces trivial code is, well, simple and trivial.

However, to write a good template that produces good code is a non-trivial task. It can take hours and hours of hard work, especially if one has not written code-generation templates. There is a particular mind-set that one has to develop in order to be able to "see" development patterns and "see" the abstraction points in a given code-base. This is, IMHO, an VERY fruitful process because it can teach a developer to think about code in an entirely different way, from a "meta-development" perspective. And so on. The point is-- it is hard to make a good template.

BTW, because of the level of difficultly involved in making a good template, I say that it is not useful to compare the LLBLGen template designer and the CodeSmith template designer. Why? Because, if we assume that each can do the "standard" template design tasks (which is a reasonable and safe assumption for 2 well-recieved and mature products), then the point is moot-- it doesn't matter WHAT template designer you use. One can produce good code or bad code with either. It depends on the template used.

Rather, what matters is... the code produced by a given template set and the supporting infrastructure code that the given template set offers. Therefore, one should compare the output of LLBLGen (for instance, the Adapter templates and the given LLBLGen core DLLs) versus the output of NetTiers (for instance, running against a given DB, with the given EntLib core DLLs).

Caveat-- Even that is not completely accurate because the LLBLGen IDE offers ways to design custom-structures (such as TypedLists) and that's not really a function of just the template. And, the infrastrcture, the stuff offered by the LLBLGen core DLLs that are used by the template-generated code, that is not really a function of the templates, but it interacts with them. That's why, for these points and others, the comparison between LLBLGen and CodeSmith/NetTiers is very fuzzy (as I have stated already) because they really are VERY different products in many ways. But, if one must compare, then one should compare the OUTPUT, the application produced by the products-- then, one can see if one is better or not.

rblinton wrote:

...Can these templates be made, "database aware", so, if we add a column to a table and regen we do not have to rework the CRUD template to see the new field on the CRUD form, etc.?...

Yes. Of course. The template design environment in LLBLGen is very powerful. It is probably just as powerful as CodeSmith.

(I only say "probably" because I am guessing. I do know what CodeSmith can do because I use it a lot. I do not know all of the functionality of the LLBLGen template designer because I have only studied it for about total of 1 hour. But, that's all it takes, really. As I am pretty familar with template-based code generation, having used it for a few years now with several different products, I can easily be relatively certain that all of the essential and extended features of code-generation are available in the LLBLGen template designer. However, as I mentioned above, our team just uses the stock, out-of-the-box, Adapter templates that ship with LLBLGen and that is fine with us.)

It is pretty common to make such templates "database aware"-- that is, it is an essential feature. That's why one would write them. If not, then there is no point in writing such templates, except for a one-time run at the beginnning of the project and that is not much of a time savings at all. So, what you are asking is really a general requirement of all template-based code generators. That is, if a code-generator cannot make templates that are "database aware", then it is not actually a code-generator. So, the answer is an obvious and essential "yes".

HTH.

Thank you.

--Mark Kamoski

mkamoski wrote:

I think that auto-generated CRUD screens "seem" like a good idea. But, I have yet to be on a project where the client said "sure, that's what we want... just plug it in".

You've got to admit that that 80% of most business application are the Display of a list of the entity items in a grid with search/filter capabilities and a single entity Add / Edit / Delete type page. The other 20% is the special sauce: business rules, business processes and then those few unique one off screens.

It would be nice to have some meta data driven UI stuff like Iron Speed. Where you actually define which fields you want columns for, which are editable, etc. Iron Speed then generates the UI/DLL/DAL for you based on the meta data that you have defined.

From the start it automatically creates Grid / Add / Edit / Delete forms for each entity. It sets up relationships too. For example, the grids have filter controls based on the FK's in the table. You can of course use the metadata to set up additional "rules". They even have an interesting twist where your grid can be printed as a report, so a good portion of your "list type" reports are done too.

BOb

pilotboba wrote:

...You've got to admit that that 80% of most business application are the Display of a list of the entity items in a grid with search/filter capabilities and a single entity Add / Edit / Delete type page. The other 20% is the special sauce: business rules, business processes and then those few unique one off screens....

Nope. I don't have to admit that. In fact, I am explicitly saying that in my experience that has never been the case.

Let me put it this way-- I have never been able to auto-generate any UI code for an application. (God knows I wanted to.)

I have been able to auto-generate...

StoredProcedureLayer-- yes.

BusinessEntityLayer-- yes.

DataAccessLayer-- yes.

UserInterfaceLayer-- no.

Why? Well, because my clients have always wanted more customization for each and every form than could be reasonably supported by a given template set. Such templates would have so many customization switches, config settings, ouput option logic switches, and so on, that they would be very tough to write and very tough to maintain and very tricky to use and, even then, they would be very likely to be less flexible than needed.

That said, I will, however, agree that that functionality that you mention (list disply, CRUD operations on object, et cetera) is available in at least 80% of the applications that I have written. However, that does not mean that that code could have been generated, because, in my case, it could not.

I agree-- I, personally, like the look of generated CRUD screens. I agree-- they could be usefule. I agree-- the could be auto-generated and at the same time offer sufficient functionality. However, I am not the customer. Maybe all of my customers have been loons (I tend to think not). But, I can say that they have been a finicky bunch with some VERY strange ideas of how to build a UI. Sure, I can coach them a bit. But, if they want X and Y is just as good but looks or behaves just a little different, I am going to have to build X.

(BTW, I just edited my post above quite a bit, so you might want to re-read it as you read the 1st version I think. You are too quick for me.)

HTH.

Thank you.

--Mark Kamoski

Good discussion I've been doing some thinking on the templates for gui screens (CRUD screens) we're working on, and one of the main problems is for example: you have an order entry screen and you want to specify the customerID. How do you do that? Pop up a customer list? What if there are 40,000 customers? So a search perhaps? but that might be cumbersome as well, so it quickly gets very sophisticated or better: needs to be sophisticated to be useful.

A screen with just textboxes is nice, but hardly useful. The meta-data in the llblgen pro project is very detailed, so I can generate the customer selector without a problem, though is it useful in practise in all situations? Probably not, so you'll end up with a choice there. But that's just one choice which can make or break the usability of a gui.

So I think mkamoski is right in this that for most projects, CRUD screens aren't going to cut it because functionality is something else than simply per-entity edit stuff. However there will be screens which can be generated. It's just how much the user is willing to accept on the usability level, or better: lack thereof

I really like to see these WebUI templates... even if they are simple CRUD UserWebControls

Here are some suggestions...

data type UI validations:

max text field length == DB field length

(Text field with only accepting numbers) or number rota-tor == DB Integer

date time(calendar) picker == DB date time

automatic null handling in dropdownboxes == DB Null able

automatic null handling in text boxes == DB Null able

tool tips == DB field Description

custom validators / summary for fields and the whole entity where business rules are defined like in JCL/CLSA .. a maybe youd could add these in directly in the designer..

customizable HTML via CSS

I tend to agree with those who call for customization of CRUD screens. Most 'real' apps wind up with a large behind-the-scenes code base for validation, auditing, etc that would be difficult to generate via template. Most programmers (I would think ) will have a set of canned code fragments that provide much of the required code-behind which the users of the product have either come to expect (ie 'Make it like Word') or are mandated by the design specs.

For example, my users are used to having the background color of an entry field change to 'HotPink' when there are unsaved changes to that field and white when the value has not changed. They also expect a tooltip to appear on those changed fields showing the original value before the change, with the ability to double-click the field to restore the original value. The 'TextChange' event code for this is stored in a code snippet that needs minor changes for any screen, since the LLBLGen Pro IEntityField object is assigned to the Tag property in order to get the original value (among other things) for that field.

One of my reasons for changing to the llbgen was to get rid of hundreds of sp's that just did crud operations.

After working with the betas I can see this was the right chioce.

My aim is to write my applications with as little code as possible.

I would like to use something like the asp.2.0 controls for gridview, formview, etc.

A companion to the llbgen datsource control.

You select it from the toolbox, llbgengridview.

Now that would be cool.

mkamoski wrote:

pilotboba wrote:

...You've got to admit that that 80% of most business application are the Display of a list of the entity items in a grid with search/filter capabilities and a single entity Add / Edit / Delete type page. The other 20% is the special sauce: business rules, business processes and then those few unique one off screens....

Nope. I don't have to admit that. In fact, I am explicitly saying that in my experience that has never been the case.

Ok,

But, the generated CRUD screens could be a start, then you can customize them as you see fit.

This is actually similar to a visual FoxPro framework I used. They had wizards that allowed you to create UI forms. There were about 5 wizards, I don't remember exactally, but basically, Grid, Parent, Child, etc. You picked the fields you wanted, other options, etc. The wizard generate the Form. From there you would modify it as needed. Even if we could get here it would be a great boost to productivity.

BOb

Otis wrote:

Good discussion I've been doing some thinking on the templates for gui screens (CRUD screens) we're working on, and one of the main problems is for example: you have an order entry screen and you want to specify the customerID. How do you do that? Pop up a customer list? What if there are 40,000 customers? So a search perhaps? but that might be cumbersome as well, so it quickly gets very sophisticated or better: needs to be sophisticated to be useful.

Have you looked at Iron Speed? They basically gen a drop down but you can set a limit to how many items are in the drop down. Also, they provide a search grid, which is by default the same grid that list those entities. However, you can create a new grid to use for the pick list. In addition you can specify stuff like required or len < 20 and such and it also gens the correct validators. It is a pretty slick system.

Also, if you want, you can write your own AJAX enabled combo box or searcher or whatever and change the template to use that. In addition to being able to generate templates there are hooks and place where you can insert your own code that is preserved from gen to gen just like LLBLGen has. You can use this to for example disable some text boxes if a certain check box is off, etc.

Have you taken a look at Olymars? It generates a UI also. they call it an Admin UI that you use for testing your business layer/rules. But, included they generate server controls lists, combos etc that are tied to each entity so you can use them to build your final screen. This is also pretty cool stuff.

BOb

pilotboba wrote:

...But, the generated CRUD screens could be a start, then you can customize them as you see fit....

Yes, I see your point.

And you do have a point.

However, this leads, (virtually inevitably), to a discussion of products like IronSpeed-- which I see is exactly what happens in a post above.

Then, we have a complex comparison, something like... (IronSpeed+ItsArchitecture) VS (CodeSmith+NetTiers) VS (LLBLGen+Adapter), and I am back to saying what I was saying all along, except now with more emphasis-- these are different products, with a different audience, with different results.

I got a demo license for IronSpeed about 2 weeks ago. I built a stock application against NorthWind SQL Server 2005. I grant, it does do a lot. It writes a lot of code, that's for sure. I am sure, however, that I would not want to use that tool. It tries to "do too much", to take the programming out of programming. It reminds me of "sourcecode-less programming" gang. I remember there was a VB6 "Visual Coding" tool, that presented a drawing surface with a bunch of drag-and-drop components and properties to be set. It looked novel, but I doubt it went anywhere.

Getting a tool to write a bunch of boilerplate code 1x, as a starting point, is an OK idea. However, as I mentioned before, the real power of code-generation comes when one has to re-generate code based on a model change.

Those products have their place; but, I just don't think those products offer the flexibility, (that is-- "the build anything mentality"), that hardcore programming tools do, such as VS.NET 2005.

IronSpeed and products like it are really trying, at some level, to replace VS.NET 2005, whether they admit it or not. That's fine. Cookie-cutter code is fine in some cases. It is not, however, Programming, (capital "P" intended). Not yet. Maybe one day we will need those kind of tools. But, right now, they don't do enough. Therefore, we still need the Swiss-Army-Knife that is VS.NET 2005. Sure, it sucks sometimes when you actually have to write some code-- but, that's true of all life-- it sucks sometimes.

Now, there ARE some products that are fully integrated. If you like IronSpeed, then you should check out a REAL MDA (model-driven-architechture) tool. Go on over to http://www.CodeGeneration.net and browse the products a bit under the MDA section. I did this a while ago and found 2 very promising tools...

Mia-Generation http://www.mia-software.com/

Constructor MDRAD http://www.i3design.co.uk/

...now THOSE are some cool tools-- especially Constructor. It offers a complete UML design studio that fits into VS.NET and can synchronize, round-trip, from UML-to-code or code-to-UML, a complete application. Very nice. I only used the time-locked demo for about 5 hours total, but it really looked like it worked. It even can sync (either way) the database itself-- change a property name--- boom, the DB is updated, change a column-datatype--- boom, the code is updated. And so on. Nice stuff. But, sadly, it is out of my budget and, I must say, it looks to be a bit ahead of its time and I must say that it may NOT work for complex stuff (I just couldn't tell in my brief review0-- but the idea is right. The same goes for MIA-Generation.

But, for MDA tools to take hold and become common, I think that a lot of changes are going to have to take place. It is going to take a lot of time. Why? Well, because such tools require a new approach to development, a new way of thinking about what code IS and how it related to information at-large. Teams and core-competencies will have to change. Management will have to be convinced. And so on. I like the ideas; but, I am not holding my breath and I sugges that no one should. Heck, I cannot even convince some of these folks (some of them developers!) to stop using green-screen-era SQL. They are not at all ready for a "living UML model".

Now, those tools make IronSpeed look like, well, a cookie-cutter code-generation GUI, no offence intended because all of these tools have their place. But, the MDA tools outclass IronSpeed, given that they are tied to modeling.

Just some food for thought.

BTW, would it be nice to have an LLBLGen template to generate a set of entity-based UserControls as a starting point-- sure. But, its not something I really need and I would have to (usually) spend a lot of time customizing the output-- so, I haven't written it or asked for it much.

That said, all of the tools are there and anyone can grab the LLBLGen Template Studio and write the template. So, there is nothing stopping anyone.

BTW, one more thing. In VS.NET 2003 we had a "Data Form Wizard". Did anyone use that? I did not, except for 1x to see what it produced. However, now, in VS.NET 2005, I just checked and it looks like the "Data Form Wizard" is gone. Is it? Well, if it is, we have to ask-- why?

IMHO.

Thank you.

--Mark Kamoski

Good discussion

I agree, good discussion here. I must admit when I first posed the question to open up discussion about the 2 tools, I had only generated Northwind examples with both tools. I saw the UserControls generated by CodeSmith and thought wow that's cool but I have yet to generate anything in a real-world environment that requires customisation and further code regeneration.

mkamoski wrote:

Why? Well, because my clients have always wanted more customization for each and every form than could be reasonably supported by a given template set. Such templates would have so many customization switches, config settings, ouput option logic switches, and so on, that they would be very tough to write and very tough to maintain and very tricky to use and, even then, they would be very likely to be less flexible than needed.

I know how custom UI code can be so my opinion on the control generation has swung back towards your viewpoint Mark. Then again, I think a set of generated UI controls even as a starting point might be helpful in our case and as you said there's nothing stopping us/anyone else from starting to generate the templates.

Well, I'm pleased to say that we have gone ahead and purchased LLBLGenPro anyway so I'm looking forward to learning the ropes and cutting out hours/days/weeks of tedious handcoding!

Thanks again everyone for the discussion

Well I can understand Marks viewpoint concerning that IronSpeed tool. It simply does to much... especially it forces you struggle with their hard coded architecture at least for the web forms I tried...

but I still stand for my opinion that generation User Controls based on the DB scheme could speed up my development work! Its like LEGO you got the pieces DB , LLCOOLGen,

UI, Reports , and then you could build your application with your custom architecture / work flow etc.

Adrian