Hi,

This is a question more aimed at the development team for LLBLGen unless anyone has had similar experiences or can shed some light on the subject

After quite a lot of time spent on trying to deepen my knowledge on presentation layers, persistence and generic frameworks I have tried to construct a GUI + Middle tier framework. The main motivation for making this is the amount of repetitive code in the presentation tier. I have tried to base the framework on the NakedObjects project. The primary interface I am currently designing the framework for is a web interface. This obviously means I cant make the architecture completely similar to the NakedObjects pattern (also note it is very very much simplified! =) ).

As it is a web interface and I am a fan of net art I have tried to make the frontend as customisable as possible. This means I am not placing the controls onto each of the webpages from the backend code. I am trying to give the designer of the pages the control to specify which fields they want to display. This currently works very well for 'simple' pages / entities. I currently have 2 main controls. InputControl and DataRepeater. They each have a property on the control called PersistedObject. This is to be set in the tag of the control by the page designer and represents the underlying object for which the control they are designing is meant to persist.

This method works - I have managed to display TypedLists, entityCollections and entities with generic paging and filtering of results. I have also managed to get the input control to generically take in any entity, validate it (check unique constraints, check for not nullable fields, transform required values, check valid field values - this requires interface methods on the entity classes) and then insert into the DB. I was primarily of the assumption that when creating something new to insert into the database users only put in a single entity at a time (I was thinking of a sign up screen or a new forum post). In these cases this design would work fine but there might be times when a designer has a form which has fields from different entities. This is a problem I have been going over and have a choice of two solutions.

1 - In the persisted object tag in the control take a string delimitated by a coma or a bar. Use the string.Split method to get these into an array of objects to be persisted. The first string (persisted object name) being the primary object to do this for.

2 - Create some new GUI controls which inherit off of label and Textbox etc. Each of these controls will have two properties. PersistedObject and Field. At runtime for an input control for example the code will then be able to get the values from each of the controls (custom textbox controls for example). The control will then create an entity of the type specified in the control (the page will contain an internal list of all entities created for this control so if one entity has already been created it will retrieve it from the list). Apply the value from the form to the entity. Then the entities will be related to eachother and a save will be committed. The entities will be able to be related / filtered through a primaryKeyArgument object I am going to create. This will contain all the primary and foreign keys for the current view so each of the entities fields can be searched for these fields and be set appropriately. This will ensure that only the correct entities are being created / updated.

So the overall question is does this sound like a reasonable way to use LLBLGen? Is there any downfall in terms of performance or design that you can see in this method?

Second question..... =)

Part of the generic framework is caching, once a call is made from the GUI control to the controller the controller fetches the required object. First of all it checks the cache, if it cannot be obtained from the cache it gets it from the DB then caches it. Currently the cacheKey is made up from the following information.

Entityname|PredicateExpression

e.g

User|Username|Equal|bob

This all works out fine at the moment (but could result it too much caching at a later stage - something which I will have to address). But the problem is the data that is fetched from the DB is also paged. The data is paged before caching as the call to FetchTypedList is passed the pagesize and the pageIndex. This means if I were to cache the data even with the paging information attached to the cacheKey I would be creating way too many objects in the cache as the users can define the page size. Is there any way around this?

The third question is a lot shorter =)

If I have an website where users can upload audio tracks. These can be made into a compilation. The compilation can have artwork assigned to it. Artwork can also be assigned to single tracks. The current DB design for this is to have 4 tables

Tracks Compilations Artwork CompliationArtwork(compliationId, ArtworkId)

As the artwork on compilations is optional I have a compliationArtwork table linking the two. Is LLBLGen able to give the CompilationsEntity an Artwork entity as a member variable? Is this possible through the designer by using the relation CompilationArtwork?

Thanks in advance, sorry for the long post =)

Also thanks for a great framework for developing with!!

Thanks

Ian