Hi Folks,

We've got a project which is growing quite fast in terms of database tables, and also the data project generated bij LLBLGen grows with this. The problem is that building the data project is starting to get too long. Especially when debugging, making little changes, build, test, retry, etc. (Ok, I do code flawlessly, so this request is more for the people I am working with ).

We are using Selfservicing, 2-classes scenario. In hindsight I think we should not have chosen this approach but should have created the derived classes ourselves, which would require only the rebuild of the derived classes project instead of the whole data project each time (including all non changed generated code).

Are there suggestions on how to refactor the current situation to a more build friendly scenario?

Any suggestions are more than welcome!

Cheers, Gab

Are you only speaking about builds from VS (coz there are some build automating tools around)?

Or are you also speaking about refreshing the catalog and generating the code from the Designer?

Hi,

I am speaking of the build I have to make during development. So when I work in de Custom Entity code (so I am not changing anything to the database or re-generate the project).

The iterative proces of:

• Write code in Custom Entity
• build data project
• test in debug mode
• find error

Until everything works like it was meant to. Every little adjustment (a predicate, relation, join, etc.) required a full build of all code in de generated data project.

This means I need to rebuild the project for each alteration, but I build ca. 90% of generated code which doesn't change, while I only change the 10% custom code.

Therefore I would like to move all custom code to a seperate Data.CustomCode project and I was wondering if someone has suggestion on how to this as effectively as possible.

Cheers, Gab

I think inheritance maight be the solution here.

Instead of modifing the generated code, you derive from the generated classes, into a separate assembly.

Say you want to put some code or modify the code of the generated CustomerEntity, then you may create another assembly which include your "MyCustomerEntity" which inherits from the CustomerEntity.

Yes, that's what I think too. But that means so much work, I hope there's another solution. So we can keep the current namingconventions with the EntityBase and Entity classes.

Watch out for inheritance, you're likely creating parallel hierarchies: Customer 1:n Order, however MyCustomer 1:n MyOrder, but 'MyCustomer' inherits 'Orders' which means the type of the element in that collection changes, as it already contains 'Order', not 'MyOrder'... not fun.

It depends on what your custom entity code is about, but likely it's about 'validation', authorization, auditing and the like. You then should move that code out of the entity and into a class which is plugged into the entity through dependency injection.

So if you could elaborate a bit about what the custom code is all about, it might help to give you the proper advice

At the moment we use it mainly for the following:

• Custom properties; used in GridViews / Reports / Labels Examples:

• Contact.FullName (combi of First + Last)

• Appointment.BeginEndText (combi of From and Till formatted to string)

• Order.OrderItemCount

• Static methods; mostly for often used retrievals, sometimes for hold default sort or prefetch

• Order.GetNonDeliveredOrdersForCustomer(int customerId)

• Appointment.GetDefaultPrefetchPath()
• NewsMessage.GetFrontpageNewsMessages()

We already use the injectables for Validation & Auditing.

thanks, Gab

The static methods could be moved to separate classes: as they methods are static, they don't operate on the state of an instance of the type they're implemented on, so you could move them to say 'OrderManager' which contains the static methods for Order typed entities. These classes then can be moved to a separate project, leaving only the properties in partial classes.

Thanks.

You're right about that architecture, we justed hoped some other suggestion would make it easier. But since we use a lot of invoking on the the data project.dll from our framework we can't mess to much in the .dll so we just have to bite the bullet.

So we need to move all none instance code to a new project. Nice Saturday job.

Just for someone else finding this thread:

We moved all static methods to helperclasses and reconnected them to the EntityClasses using Extension methods.

So static methods with 'this' in front of the parameter