Hi all,

I'm not sure if I'm using the correct terminology in the title. I'm using LLBLGen 2.6 with the adapter templates. I have a rather large entity 'Job'. This entity has properties which can be logically grouped together (for example, the job's project manager properties: FirstName, LastName, PhoneNumber, etc). These groupings, however, don't require or have primary keys and thus, are not entity candidates.

It'd be nice to be able to work with these logical groupings as objects in code. It would make it easier to work with related data and see what type of data is in the job entity.

Basically, I'd like to setup an LLBLGen project so that the following code is possible:

var projectManager = new ProjectManager();
projectManager.FirstName = "Deeno";

var job = new JobEntity();
job.ProjectManager = projectManager;

adapter.SaveEntity(job, true);

Where ProjectManager is not an entity that I can fetch/save on its own.

Thanks

I have a rather large entity 'Job'. This entity has properties which can be logically grouped together (for example, the job's project manager properties: FirstName, LastName, PhoneNumber, etc). These groupings, however, don't require or have primary keys and thus, are not entity candidates.

Separate these group of properties in another tables (extension tables), with PK set as a FK to the Job entity PK. (1:1 relation) And in LLBLGen Pro, let these extension tables inherit from the Job entity, so that no sub-Entity can exist on its own without the root Job entity.

Thanks for the help. This gets me a little closer but still doesn't solve the problem

The issue here is project manager doesn't have a 'is a' relationship with job. Job, instead, 'has a' project manager. So inheritance isn't appropriate.

My JobEntity is large. I have many fields with prefixes to group them together but its getting cumbersome. I want to simplify the entity by composing it of poco classes.

I've created extension tables (which might help, but will cost me on query complexity). However, with the proposed solution I can't write:

var job = new JobEntity();
job.ProjectManager = new ProjectManager();

Additionally, by inheriting from job the new ProjectManagerEntity is not only semantically incorrect but makes the field complexity problem a little worse. PorjectManager now has all the fields Job does. To be clear, with the proposed solution I CAN, but shouldn't be able to write:

var pm= new ProjectManagerEntity();
pm.BudgetStatus= // budget status is data relevant to a job not a project manager

Other thoughts? Am I missing something?

The ideal approach is separate the table in other tables (groups) as you proposed. Otherwise the only alternative is the one pointed (multiple entity version plus inheritance). I know that could be semantically incorrect, but it's a workaround. As I said, the best approach is separate the table into other tables, all joined in 1:1 relations.