Hi,

I need an advice. Anyone would be good !!!

I do an Asp.net project with grid. I need to show data in a grid that come from 5 differents entities (all related together).

What is the best (good) way to do it in term of simplicity and/or performance and/or maintenance ???

The way is used to do it now: I create a view in the database, map the view in llblgen as an entity (easier to work with than TypedView) and work with that.

The problem I see is: it will soon fill the database with views and it will be difficult to differenciate real entities from the views. There should be a better solution but I don't know it...

Thanks.

HI Wally,

Do you need to merge 5 different entity types in one Grid at once? or Do you need to use LLBLGenProDatasource to bind 5 different entity types to a grid, one after another?

Hi,

5 differents at the same time.

Example: The way the electrical model for distribution is designed in Quebec (Canada):

• There is territories (5)
• There is a station where Hi voltage arrive and is lowered and splitted into line say 100 per territory
• There is a line that bring electricity to home say 100 per station
• There is transformers lowered voltage before entering in home, say 1000 per line
• There is measurement intruments on some transformers (Measure points)
• Each measure points need to be identified with each part of its parent in the hierarchy.

I made a view on the "lineDetail" that flatten all details of its parent hierachy. I also created a relation between transformers and "lineDetail". But when it come to get lineDetails to measurePoint I don't know how to do it in a clean way... Without having to define another additional view. Also, I cannot add all fields of the lineDetail into a transformers (fields on related fields), it would be bad design.

Do you have an idea ? To me, it would be nice to be able to flatten any related objects like a regular SQL query. The easy part would be that all relations would be simplier to set.

...

In terms of good design I'll choose a TypedList for simplicity and a DynamicList for flexibility. Try to figure out how the SQL-query would be and let us known if you need help to translate it to LLBLGenPro.

Thanks Goose.

I forgot the TypedList. I will probably use that. I didn't know DynamicList and I took a look. I found it too complex to use... too much code for so little advantages. It need some improvement there... I think.

Anyway, thanks a lot to remiember me the typed list. I already used it but I don't remember why but I stopped.

In fact, it's bad because it is not something I will re-use. Then it should be define only at the code level where I use it. But the dynamic list should be improve to be easier to use. I have another thread open actually that discuss that. It is related the a collectionViewerFlatner (see relational tables on a flat view). I will see if we can get a new feature for that.

Thanks. Eric

SelfService example.

ResultsetFields fields = new ResultsetFields(3); fields.DefineField(EmployeeFields.FirstName, 0); fields.DefineField(EmployeeFields.LastName, 1); fields.DefineField(DepartementFields.Name, 2);

RelationCollection relations = new RelationCollection(); relations.Add(EmployeeEntity.Relations.DepartementEntity...);

DataTable dataTable = new DataTable(); TypedListDAO dao = new TypedListDAO(); dao.GetMultiAsDataTable(fields, dataTable, 0, null, null, relations, true, null, null, 0, 0);

DynamicLists are simple to use, as shown on the above piece of code, in its simplest form, fetching column from more than one table, requires you to define those fields (fair enough), and define the JOIN relation used to fetch them And call the fetch method.

That's it.

Hi Walaa !

Thanks for the sample. I saw it in documentation. But thanks to remind me. I'm re-thinking about using it. But for the moment I tilt on the side of not using it.

To me simple = 1 or 2 lines.

Its not that it is so complex, it's just that it should exist a way to it more easy and also, without having to set each fields one by one.

Being able to set fields is a nice feature where performance is crucial but to me, there is too much disavantages that I don't want to use that...

The bigger disavantages is that on any database change I will have to track down everywhere in the code where I was using those fields and programmatically correct the problem. I should be able to have a view of related entities (with all fields) on an easy manner without having to set each fields one by one. I think that I should be able to only ask entity types (and filters) and LLBLGen does the everything else. In a good database design, it should be easy to do (for LLBL team and us), easier to program, manage, maintain. It can throw an exception if it found no path (a way) to relate all entity types or an exception if it find more than one way. For the more than one way, it could be solved if we can give weight on relation at design time. (... I'm dreaming !!! sorry !!!).

... Thanks for your help !

Oups,

I just red another message in another thread.

I was wrong.

Dynamic list are not late binding. Then it is more usefull that I thought. It is long to set (at my opinion) but I changed my vision and will use them.

Thanks!