Has anyone here used Deklarit? Have any comparisons to LLBLGEN Pro? From my limited look at it it appears to be a bit black-box...at least moreso than LLBLGEN Pro which is a bad thing.

So, could someone give me a quick list of its shortcomings/advantages, or point me to a good source other than their website

Its core is designer based, which means that everything you do / change/want has to be done through the designer.

In small projects that might be ok, in 1000+ table projects it IMHO is not that great.

Otis wrote:

Its core is designer based, which means that everything you do / change/want has to be done through the designer.

They use editable templates also, right? One thing that is scary is that it will actually make changes to your database, although it warns you if you are about to make changes.

In small projects that might be ok, in 1000+ table projects it IMHO is not that great.

Why is it not good for larger projects? I read your posting about it requiring regeneration on any change to a business rule (wow), but is there anything else?

mikeg22 wrote:

Otis wrote:

Its core is designer based, which means that everything you do / change/want has to be done through the designer.

They use editable templates also, right? One thing that is scary is that it will actually make changes to your database, although it warns you if you are about to make changes.

Well, 1 thing I'll not do is doing DeKlarit's marketing, sorry

In small projects that might be ok, in 1000+ table projects it IMHO is not that great.

Why is it not good for larger projects? I read your posting about it requiring regeneration on any change to a business rule (wow), but is there anything else?

It's my understanding you have to define every filter in the designer, which basicly comes down to having a lot of filters/queries in the designer when a lot of entities are defined. So when you have a couple of developers in your team, they all have to design their filters in the designer.

Otis wrote:

Its core is designer based, which means that everything you do / change/want has to be done through the designer.

In small projects that might be ok, in 1000+ table projects it IMHO is not that great.

I've been using DeKlarit for some time, and came across your program and find it very interesting. (to say the least!!!) I think I'm about ready to switch, but I have a couple of questions I hope you can answer for me.

1st, One feature I've grown to love with DeKlarit is the use of Domain:Enum's.

Basically you declare an Attribute as type ENUM, and populate it with items. Then you define an Entity's Attribute as the ENUM type you just created. Obviously it stores the datatype as int, but in the code, whenever you call on the entities attribute you are given the ENUM as the possible values for the type.

Does your program have this functionality, or a way to implement this type of functionality? If not, is it possible to add this functionality to your version 2 program?

2nd, I moved from ORM.NET (back before it was open source) to DeKlarit because I found it to dramatically slow down over time. When the database had just a few records in it, the application was nice, over time, it would end up taking longer and longer to do the same code (which was unacceptable and thus I found DeKlarit and found that it's speed remains relatively the same whether working with 100 records, or 100,000 records give or take a second or two)

Using DeKlarit, I find there are times I don't want to load the entity and all it's releational entities into memory everytime I want to change one atttribute. So what I would do is create smaller entities that map to the same data. For example, I have a MEMBER, a MEMBER has CONTACTS, LOGINHISTORY, etc... The LoginHistory could get rather large over time, and I wish not to load the LoginHistory everytime I wanted to update the Member's Contact data, so I created a MemberContact, and a MemberLoginHistory entity where Member was the 1st level data (and the same throughout all the entities), and the Contact / LoginHistory was a level below.

The problem with this is I had to call (depending on which data I'm looking for the correct Entity) whereas with your program it looks like I can call just the main "MEMBER" entity, and I have access to each related entity from there.

While reading through your documentation I see that LLBLGenPro using "Lazy Loading"...

My question, does this mean that each attribute is loaded when it's being called, or each entity is loaded when it's called? If each entity, does this mean that when I first load the main MEMBER entity, it loads just that table, and only when I try to access the LOGINHISTORY related entity does it add all the login history records to the MEMBER entity??? and how well does LLBLGen Pro work when the database gets quite huge?

Awaiting your response,

There is a mechanism available to create type converters for different sql data types, which you can use to convert any type of field you wanted to an enum if you needed too. Here's confirmation http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4409 .

Your thoughts on lazy loading are exactly correct. In your situation you load the member entity. The loginhistory collection is not loaded until you reference it. You can of course modify this behavior by defining what are called prefetch-paths to load the collections and other entities at fetch to help with performance if you know you will be interacting with the related fields.

The software is very good at scaling, you just have to be intelligent with your queries and if you run into any issues Frans and everyone else on the board are very helpful with getting things working the way that you want them too.

bclubb wrote:

There is a mechanism available to create type converters for different sql data types, which you can use to convert any type of field you wanted to an enum if you needed too. Here's confirmation http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4409 .

Your thoughts on lazy loading are exactly correct. In your situation you load the member entity. The loginhistory collection is not loaded until you reference it. You can of course modify this behavior by defining what are called prefetch-paths to load the collections and other entities at fetch to help with performance if you know you will be interacting with the related fields.

The software is very good at scaling, you just have to be intelligent with your queries and if you run into any issues Frans and everyone else on the board are very helpful with getting things working the way that you want them too.

Will version 2 support ASP.NET 2.0 DataSource like DeKlarit does? Thier new v4 product comes with a DeklaritDataSource that allows one to use the new time saving features of ASP.NET 2.0 databinding controls.

Also, are there any code examples of how to implement the ENUM features described in the above thread?

C4 wrote:

bclubb wrote:

There is a mechanism available to create type converters for different sql data types, which you can use to convert any type of field you wanted to an enum if you needed too. Here's confirmation http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4409 .

Your thoughts on lazy loading are exactly correct. In your situation you load the member entity. The loginhistory collection is not loaded until you reference it. You can of course modify this behavior by defining what are called prefetch-paths to load the collections and other entities at fetch to help with performance if you know you will be interacting with the related fields.

The software is very good at scaling, you just have to be intelligent with your queries and if you run into any issues Frans and everyone else on the board are very helpful with getting things working the way that you want them too.

Will version 2 support ASP.NET 2.0 DataSource like DeKlarit does? Thier new v4 product comes with a DeklaritDataSource that allows one to use the new time saving features of ASP.NET 2.0 databinding controls.

Yes. It's the only way to do normal design time databinding in .NET 2.0. We'll also extend the way collections are bound to grids in complex databinding scenario's, with objectview objects which you can sort/filter using the normal predicate/sort clause classes. (thus typed)

Also, are there any code examples of how to implement the ENUM features described in the above thread?

I'll mail you the SDK .chm file, which contains the description how to program a type converter. I'll also enclose the sourcecode of the typeconverter shipped with llblgen pro (which converts int/byte etc. to bool and back) as an example. The SDK is normally for customers only, but in this case you need the .chm file to learn about writing type converters.

(edit) : mailed to the email address you specified when you registered on the forum. If you don't received it, please let me know.

C4 wrote:

... Using DeKlarit, I find there are times I don't want to load the entity and all it's releational entities into memory everytime I want to change one atttribute. So what I would do is create smaller entities that map to the same data. For example, I have a MEMBER, a MEMBER has CONTACTS, LOGINHISTORY, etc... The LoginHistory could get rather large over time, and I wish not to load the LoginHistory everytime I wanted to update the Member's Contact data, so I created a MemberContact, and a MemberLoginHistory entity where Member was the 1st level data (and the same throughout all the entities), and the Contact / LoginHistory was a level below.

The problem with this is I had to call (depending on which data I'm looking for the correct Entity) whereas with your program it looks like I can call just the main "MEMBER" entity, and I have access to each related entity from there.

While reading through your documentation I see that LLBLGenPro using "Lazy Loading"...

Selfservicing supports lazy loading, adapter does not. This is by design, as Adapter is suitable for disconnected systems, like when you have a BL tier on another system than the GUI tier. Triggering lazy loading in the GUI tier isn't what you want in that scenario. Also, if your GUI team isn't allowed to do their own calls to the persistence logic but have to call BL code, you can do so with adapter, as you need an adapter object to perform persistence logic.

LLBLGen Pro supports dynamic lists and typed lists to create lists of readonly data and dynamic lists can be created in code using the entity meta-data. You should also have a look at prefetch paths which give you a large set of features how to fetch the additional data related to an entity or set of entities.

Otis wrote:

Yes. It's the only way to do normal design time databinding in .NET 2.0. We'll also extend the way collections are bound to grids in complex databinding scenario's, with objectview objects which you can sort/filter using the normal predicate/sort clause classes. (thus typed)

Is there a timeframe on a beta build that will support this functionality? I have a project that is being built on ASP.NET 2.0 that I'd like to use your LLBLGen Pro on, but time is of the essence as the client is looking for results ASAP, and I don't want to do a lot of rewrite converting the old style databinding to the new style databinding. Also, I would assume as a show of good faith, purchasing a 1x at this point in time would qualify for a free 2x upgrade?

Otis wrote:

I'll mail you the SDK .chm file, which contains the description how to program a type converter. I'll also enclose the sourcecode of the typeconverter shipped with llblgen pro (which converts int/byte etc. to bool and back) as an example. The SDK is normally for customers only, but in this case you need the .chm file to learn about writing type converters.

(edit) : mailed to the email address you specified when you registered on the forum. If you don't received it, please let me know.

In looking at the code you sent, I'm left with the impression that for each ENUM type, a new converter type will need to be built. Is it possible to make a generic ENUM Converter Type that can be resued for various ENUM classes? Maybe calling an ENUM class as a parameter. Below is a sample enum class code:

    public enum UserRoleTypes {NotSet=-1, Administrator=0, OfficeManager=1, Mentor=2, Scheduler=3, Student=4, ReferralCompany=5};
   public class UserRoleTypesMetaData
   {
      public static string[] Descriptions = new string[] {"Not Set", "Administrator", "Office Manager", "Mentor", "Scheduler", "Student", "Referral Company"} ;
      public static UserRoleTypes[] Values = new UserRoleTypes[] {UserRoleTypes.NotSet, UserRoleTypes.Administrator, UserRoleTypes.OfficeManager, UserRoleTypes.Mentor, UserRoleTypes.Scheduler, UserRoleTypes.Student, UserRoleTypes.ReferralCompany} ;
      public static string GetDescription( UserRoleTypes enumValue )
      {
         return Descriptions[System.Array.IndexOf( UserRoleTypesMetaData.Values, enumValue)] ;
      }

   }

If so, can you please send me a code example of how to implement this?

C4 wrote:

Otis wrote:

Yes. It's the only way to do normal design time databinding in .NET 2.0. We'll also extend the way collections are bound to grids in complex databinding scenario's, with objectview objects which you can sort/filter using the normal predicate/sort clause classes. (thus typed)

Is there a timeframe on a beta build that will support this functionality? I have a project that is being built on ASP.NET 2.0 that I'd like to use your LLBLGen Pro on, but time is of the essence as the client is looking for results ASAP, and I don't want to do a lot of rewrite converting the old style databinding to the new style databinding. Also, I would assume as a show of good faith, purchasing a 1x at this point in time would qualify for a free 2x upgrade?

We hope to be done with programming functionality at the end of 2005, so a beta will start then and will hopefully lead to a succesful launch around february/march at the latest. The beta will initially be closed and only be open for selected beta-testers. This is to be sure the beta testers also perform real beta testing with the code, as most beta testers often just kick the tires and not use it in production.

Customers of the 1.0.200x.y codebase will have to pay 49euro per developer (who uses the designer) for v2.0

Design time databinding has changed dramatically in asp.net 2.0, and the 2-way databinding they've implemented is broken if you consider changetracking, because it will re-create a new object on the postback, not re-using an existing object. Databinding at runtime works of course, you just miss the design time databinding for now.

Otis wrote:

I'll mail you the SDK .chm file, which contains the description how to program a type converter. I'll also enclose the sourcecode of the typeconverter shipped with llblgen pro (which converts int/byte etc. to bool and back) as an example. The SDK is normally for customers only, but in this case you need the .chm file to learn about writing type converters.

(edit) : mailed to the email address you specified when you registered on the forum. If you don't received it, please let me know.

In looking at the code you sent, I'm left with the impression that for each ENUM type, a new converter type will need to be built. Is it possible to make a generic ENUM Converter Type that can be resued for various ENUM classes? Maybe calling an ENUM class as a parameter.

The problem with enums is that they can't be inherited from a base enum, so you need to define a type converter for every enum. This might be a lot of work, I don't know. What I do know is that the data from the db and to the db has to be converted to be sure it always works. (e.g.: on sqlserver, it does work: an enum is converted to an int behind the scenes, on oracle it doesn't)

Otis wrote:

C4 wrote:

Otis wrote:

Yes. It's the only way to do normal design time databinding in .NET 2.0. We'll also extend the way collections are bound to grids in complex databinding scenario's, with objectview objects which you can sort/filter using the normal predicate/sort clause classes. (thus typed)

Is there a timeframe on a beta build that will support this functionality? I have a project that is being built on ASP.NET 2.0 that I'd like to use your LLBLGen Pro on, but time is of the essence as the client is looking for results ASAP, and I don't want to do a lot of rewrite converting the old style databinding to the new style databinding. Also, I would assume as a show of good faith, purchasing a 1x at this point in time would qualify for a free 2x upgrade?

We hope to be done with programming functionality at the end of 2005, so a beta will start then and will hopefully lead to a succesful launch around february/march at the latest. The beta will initially be closed and only be open for selected beta-testers. This is to be sure the beta testers also perform real beta testing with the code, as most beta testers often just kick the tires and not use it in production.

Customers of the 1.0.200x.y codebase will have to pay 49euro per developer (who uses the designer) for v2.0

Design time databinding has changed dramatically in asp.net 2.0, and the 2-way databinding they've implemented is broken if you consider changetracking, because it will re-create a new object on the postback, not re-using an existing object. Databinding at runtime works of course, you just miss the design time databinding for now.

Otis wrote:

I'll mail you the SDK .chm file, which contains the description how to program a type converter. I'll also enclose the sourcecode of the typeconverter shipped with llblgen pro (which converts int/byte etc. to bool and back) as an example. The SDK is normally for customers only, but in this case you need the .chm file to learn about writing type converters.

(edit) : mailed to the email address you specified when you registered on the forum. If you don't received it, please let me know.

In looking at the code you sent, I'm left with the impression that for each ENUM type, a new converter type will need to be built. Is it possible to make a generic ENUM Converter Type that can be resued for various ENUM classes? Maybe calling an ENUM class as a parameter.

The problem with enums is that they can't be inherited from a base enum, so you need to define a type converter for every enum. This might be a lot of work, I don't know. What I do know is that the data from the db and to the db has to be converted to be sure it always works. (e.g.: on sqlserver, it does work: an enum is converted to an int behind the scenes, on oracle it doesn't)

Ok, after a few weeks of playing with this software I belive it is an extremely valuable tool and have been able to reproduce 99% functionality of using DeKlarit. With that, I've purchased my license (Order #E813734)

Functionality that I miss from DeKlarit are the "formula enabled" calculated fields. I hope to see this functionality introducted in the next verion 2. Speaking of V2...

Now that I am a full fledge owner and am using this on a production application for a client I would like to participate in the v2 Beta, as I will put it to good use in a production environment. (not just kick the tires)... May I please be included in the official beta testing of V2????

Welcome aboard. Having closely evaluated Dekalit like you did, I can assure you that you made a very wise decision to go with LLBLGen Pro.

The power is Deklarit is obvious after having tried it for a few days. Once you've mastered the UI you find that it does what it does and that's about it. There's not alot "under the covers".

The power of LLBLGen Pro is much more difficult to ascertain at first. After a year of use, I'm still discovering new functionality. Interesting thing about LLBLGen - - the more you use and understand it, the more impressed you become. Not so with Deklarit.

Deklarit has a simple learning curve compared to LLBLGen. LLBLGenPro is a tool designed by a master programmer for use by professional developers. It takes time and effort to develop your framework with LLBLGen. But, once you do, you will be very pleased with the quality and performance of your code.

Last thing: using LLBLGen, studying the code that it generates and interacting with Frans and others on this forum has MOST DEFINATELY made me a better programmer. In other words, using the code generated by LLBLGen Pro has compelled me to follow well established coding techniques that have led to very clean, very professional and very functional code. Building your code around LLBLGen generated objects is an exceptional roadmap that will lead to successful applications.

Jeff

C4 wrote:

Ok, after a few weeks of playing with this software I belive it is an extremely valuable tool and have been able to reproduce 99% functionality of using DeKlarit. With that, I've purchased my license (Order #E813734)

Functionality that I miss from DeKlarit are the "formula enabled" calculated fields. I hope to see this functionality introducted in the next verion 2. Speaking of V2...

Yes, they're on the 'must include' list of features for v2. We've a couple of lists for v2.0, one is a list of features which have to be in v2.0 before it's shipped and another couple of lists with lower priority, so if time is running out these are postponed, but not the expression stuff.

Now that I am a full fledge owner and am using this on a production application for a client I would like to participate in the v2 Beta, as I will put it to good use in a production environment. (not just kick the tires)... May I please be included in the official beta testing of V2????

We're considering an open beta for all our customers (read: it's very likely the beta will be open).

Jeff wrote:

The power is Deklarit is obvious after having tried it for a few days. Once you've mastered the UI you find that it does what it does and that's about it. There's not alot "under the covers".

Agreed. It's very 'designer oriented': you've to use the designer for everything. While that can be handy at times, I found it a limiting factor after half an hour (we regularly look at competitors ). It depends on the person I guess, but I prefer typing in a line of code over fiddling with a UI for 5 minutes.

The power of LLBLGen Pro is much more difficult to ascertain at first. After a year of use, I'm still discovering new functionality. Interesting thing about LLBLGen - - the more you use and understand it, the more impressed you become. Not so with Deklarit.

Deklarit has a simple learning curve compared to LLBLGen. LLBLGenPro is a tool designed by a master programmer for use by professional developers. It takes time and effort to develop your framework with LLBLGen. But, once you do, you will be very pleased with the quality and performance of your code.

Thank you!

One core focus point for v2.0 is a much better way to access the power in the code generator, to feed it with much more meta-data and to customize it much easier, one thing DeKlarit does well and we don't do that well, even though our code generator engine is more powerful.

Last thing: using LLBLGen, studying the code that it generates and interacting with Frans and others on this forum has MOST DEFINATELY made me a better programmer. In other words, using the code generated by LLBLGen Pro has compelled me to follow well established coding techniques that have led to very clean, very professional and very functional code. Building your code around LLBLGen generated objects is an exceptional roadmap that will lead to successful applications. Jeff

We're considering an open beta for all our customers (read: it's very likely the beta will be open).

I hope you do make it open beta as i shouldnt be to far along in my project and i would love to use it.

Otis wrote:

We're considering an open beta for all our customers (read: it's very likely the beta will be open).

Sign me up... and include me on the mailing list... Awaiting V2 Beta