Hi all

I'm looking into possible alternatives for our homegrown but somewhat dated ORM mapping tool. I've used LLBLGen in the past and was quite happy with it, and the option to generated EF4 code is great.

However, we relay on code generation not only based on the entity model of our database, but also concrete meta data, e.g. enum generation, settings classes based on key/value pairs (the Key becomes the property name), or validation metadata for attribute creation. This means that for code creation, we would need to access the actual data in some of our tables. I could use T4, or most likely CodeSmith, but a dedicated tool would be desirable for us.

Is this possible with custom custom templates in LLBLGen?

Thanks for your advice Philipp

Hi Philipp,

Most of those things are already built-in just ready to use them:

• Enum type import definitions

• Attribute definition

• Defining and consuming custom settings

You can do a lot with that. If there is something you cannot do, you can write your own templates. For a start on that read the SDK docs

Hi Daelmo

Thanks for the reply! Looking quickly through the docs, I'm not sure whether this is the functionality I'm looking for. I want to generate classes based on data in the database, not link to existing types. So for example, if my settings table contains 20 records, I want to end up with a Settings.cs class that has 20 properties, e.g

Table row: Name: "LookbackRange" DateType: System.Int32 Value: 10

//dummy code
public int LookbackRange
{
   get { return Resolve<int>("LookbackRange");
   set { Set<int>("LookbackRange", value); }
}

This means that if a user edits one of those tables, I want to regenerate the code in order to reflect that additional property.

The same goes for enums: They don't exist in my model, but I want them to be generated according to the data in my database. Again, 5 records means and entity with 5 possible values (or 6, if I wanted to generate a default value).

Thanks for the clarification Philipp

daelmo wrote:

Hi Philipp,

Most of those things are already built-in just ready to use them:

• Enum type import definitions

• Attribute definition

• Defining and consuming custom settings

You can do a lot with that. If there is something you cannot do, you can write your own templates. For a start on that read the SDK docs

This means that if a user edits one of those tables, I want to regenerate the code in order to reflect that additional property.

Would the user get back to you to re-generate and build the code, every time he adds new values? Or do you plan on automating this? Would you please explain why do you need to convert data into code (properties)..etc.

Walaa

Walaa wrote:

This means that if a user edits one of those tables, I want to regenerate the code in order to reflect that additional property.

Would the user get back to you to re-generate and build the code, every time he adds new values? Or do you plan on automating this? Would you please explain why do you need to convert data into code (properties)..etc.

Yes, we are talking about data that is maintained by the dev team, and not regular users of the system. I could think of both manual regeneration or automating the process.

The reasons for this are quite a few, actually.

One thing is that this is because we are doing this today. I'm talking about a huge enterprise system that can't be down even for an hour. Based on that data, thousands of classes are being generated: Settings, enums, service clients etc. Basically, this part of the database is a huge repository of meta data.

We need to ensure a smooth transition, and this means that we will have to respect parts of our infrastructure, which is highly automated.

Another thing is overhead. This is a data driven system, and we are generating even UI code based on that data, which allows us to basically add some data to our database and trigger code-gen in order to create a whole UI/client/data tier. We don't want to lose that.

Furthermore, code-gen, e.g. of enum values is convenient and robust (we don't have to write the enums ourselves and map them to database values). It also ensures that the actual data and our code is in sync anyway. With hand-written enums that are mapped to your database, you could easily get them out of sync by adding/removing a row in the database. In our case, this would break the system which would automatically being detected through automated builds.

The same goes for a settings class. Given that I can just add a row with a key/value pair to the table and then automatically get a properly named and strongly typed property in a generated class, the prospect of writing that code by hand doesn't sound like a step into the right direction

Cheers, Philipp

Well, writing .lpt templates is like writing any piece of C# code. That means you can do a lot of stuff there. This is an example of how a piece of .lpt access database generates code based on live data: http://llblgen.com/tinyforum/Messages.aspx?ThreadID=16775&StartAtMessage=0&#94029

You just need to get started reading the SDK docs (see the link in my first post), and then give it a try.