Please keep in mind that I am newbie to LLBL ( and entity framework in general).

So far I have written the code using LLBL and basically what I am getting are some objects( entity, collection, relations etc) around my database items(table, fields, relationships etc). But I think what I will be more interested in is getting are the objects that map against my business entities, which can spam one or more multiple database entities. Any idea how can I do that using LLBL framework?

I'm a noobie too, have a look at the Northwinds example on the examples page. Look at the Manager Classes.

I find it difficult to decipher, but it helps somewhat.

It would be really nice to have a really good fully populated business object example floating around somewhere.

If there was I reckon it'd lower the barrier of entry for a lot of people (including me)...one can dream tho

Thanks John, I am getting exactly same feeling about not finding a good working business object example somewhere here ( or may be I just need a new set of eyes )

I am hoping someone from LLBL team can point to some good links on it

I think it depends on what a Business Object means really as that definition is really ambiguous. So for example, do you consider a class called 'Order' which contains a reference to a Customer entity, an order entity and its order details entities a business object? As others don't (e.g. people using DDD, who think in aggregate roots)

Well basically what I am looking for is a solution where I can have an object that combines several columns across multiple database tables. Because really that's how some of business objects are defined in my layer and I was wondering what could be best way of doing it within LLBL.

well, I reckon those DDD dudes (who obviously think too much).....haven't thought of us noobies...cause now I gotta go Google what the hell aggregate roots are...Don't they know my greed for lust and power far exceed my desire for professionalism?!

I agree with Google Number 4: Don't Create Aggregate Roots

Cause it just made my head hurt

K I'll shut up now, but I do like imakimak's question

I hope I haven't asked a stupid question here to LLBL gurus, coz I see other questions been answered on the forum but for some reason this has been largely ignored

Question isn't stupid (and architecture forum is considered lower priority than the other forums, so your question might be here for a few days before getting an answer).

Objects across several tables are in your system readonly? Or read/write? as writing them is going to be a problem in that case.

Several years back we thought about adding this, but when we started the work, (e.g. 'businessOrder' for example would have reference to customer, order and order details), it turned out that designing them in a designer would actually make things complicated where writing them in code would be easy. So we left it to the developer.

What you're after is likely answered with a typed list. Have you looked at typedlists? (unless you want writable data of course, typedlists are readonly)

I haven't looked at the typed list but these objects that I have are read/write. Although there aren't too may like these in the system, large majority of these are read-only. So is this some kind of limitation with LLBL framework? Are there anyways of addressing it?

PS: What are the highest priority forums? I will just post my question there

imakimak wrote:

I haven't looked at the typed list but these objects that I have are read/write. Although there aren't too may like these in the system, large majority of these are read-only. So is this some kind of limitation with LLBL framework? Are there anyways of addressing it?

PS: What are the highest priority forums? I will just post my question there

the other forums under 'LLBLGen Pro' are of higher priority.

Writable objects in these cases can best be written manually, by aggregating some entities yourself. You can then fetch them using a set of queries ran in a method, and saved by using a UnitOfWork (2) object.

Entities across multiple tables is currently not supported, we will add this in the 3.x timeframe, likely later this year. This always has the limitation of the necessity of a 1:1 pk-pk relationship between the tables the entity is mapped on. So you can work around this by using inheritance (which can thus map an entity on multiple tables (the subtype), or by using the related table entity as a related object and by using FIelds mapped onto related fields in the designer to map the fields of the related entity into the main entity.

A problem with business objects as well is the separate hierarchies: if you have a Customer entity which contains an Orders collection, the order objects are inside the Customer. However if you have a separate object which contains a Customer and a set of Orders, there's no association between customer and orders and therefore recursive saves are not possible.