Is there a way to specify which fields of an entities will or will not be persisted? i am trying to persist entities to the viewstate and/or session state to have access to them across multiple postbacks in a .NET web app, but i don't need to persist all of the related collections and data which may have been loaded into that entity.

Mmm. I'm no t sure. What you can do is clone just the entity you want to save to the viewstate.

SomeEntity toSaveOnVS = new SomeEntity(theOriginalEntity.Fields.Clone());
...

I'm with you on the idea of cloning the object. Two things:

1. in this case theOriginalEntity is of an abstract class, so i can't create a new one as there is no constructor.

2. even if it were not abstract, I don't see any constructor available to my entity classes that takes EntityFields as a parameter.

triple post!

i posted three times because i got an application error upon posting. please check your website. i will copy and paste the code here:

Server Error in '/TinyForum' Application.

Runtime Error Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

<configuration> <system.web> <customErrors mode="Off"/> </system.web> </configuration>

What exactly did you post? Could you describe that so we can reproduce it perhaps? I'll check the event log.

(edit) I think it was a memory issue. The Sqlserver process took a lot of memory (configured to do so), I limited it to less memory so the sites have breathing room.

my first reply is what triggered your error.

Answering your original question.

It's a best practice not to store complex objects in the Session or in th ViewState, but rather simple data types, that's for performance reasons.

So you'd better only store the fields you need (eg. CustomerName, CustomerID, ...etc.) Each in its own Session or Viewstate variable.

okay, now we are getting into an area which touches on how to architect a web page. let me explain more.

what i am doing is building a wizard which serves both to create and edit a fairly complex entity which involves the creation of related entities end collections of entities. i need to persist these entities across multiple postbacks because i don't want to put them into persistent storage (the DB) until the final step.

Additionally, because some of the components of the wizard are usercontrols, these usercontrols might be uuseful in other contexts and so they take as inputs Entity objects which are then also persisted.

For example an OrderGrid might make use of an OrderEditorUC (usercontrol), which might also be used on an EditOrderPage; both the OrderGrid and the EditOrderPage supply an OrderEntity to the OrderEditorUC, and read it out of the OrderEditorUC when everything is set for a Save() to DB.

for this reason i thought it would be good to construct these entities and collections and persist them in the application (session or viewstate), rather than continually rebuilding entities across postbacks from sets of primitive data types, as you suggest.

What do you think?

I see your point of view, but would you please further explain the following in the context?

Is there a way to specify which fields of an entities will or will not be persisted? i am trying to persist entities to the viewstate and/or session state to have access to them across multiple postbacks in a .NET web app, but i don't need to persist all of the related collections and data which may have been loaded into that entity.

gladly.

The main object i am dealing with is an EvidenceEntity. It contains a Collection of EvidenceQuestionGroupAssignments. This collection of entities relates my Evidence to a set of QuestionGroups.

What i have is a usercontrol which is basically managing a grid of these EvidenceQuestionGroupAssignments. It can create new assignments and edit existing ones (including creating QuestionGroups etc.)

This user control in additon to persisting it's colection of entities, also persists the EvidenceEntity in order to have it ot create new EvidenceQuestionGroupAssignments. These are created basically like this:

        Dim eqga As New EvidenceQuestionGroupAssignmentEntity
        With eqga
            .Evidence = evidence ' the persisted evidence
            .QuestionGroup = group
        End With

I have begun by retrieving the collection EvidenceQuestionGroupAssignments from the original Evidence, like so:

    Public Sub SetFromExistingEvidence(ByVal evidence As EvidenceEntity)
        Me.Reset()
        Me.SelectedQuestionGroupAssignments.AddRange(evidence.EvidenceQuestionGroupAssignment)

        ' sort the collection
        Me.SelectedQuestionGroupAssignments.Sort(EvidenceQuestionGroupAssignmentFields.SortOrder.FieldIndex, ComponentModel.ListSortDirection.Ascending)
        Me.BindSelectedQuestionGroups() ' bind the usercontrol
        Me.PersistSelectedQuestionGroupAssignments() ' persists the collection
    End Sub

The collection that im interested in here is being "double persisted" -- once as the collection SelectedQuestionGroupAssignments persisted in my usercontrol (session or viewstate or whatever), and a second time as the collection belonging to the Evidence (myEvidence.EvidenceQuestionGroupAssignments) which has also been persisted to session.

So i would like to persist the Evidence (myEvidence) so ican use it to create assignements, but not persist myEvidence.EvidenceQuestionGroupAssignments.

Bear in mind that in some contexts we are talking about evidence that comes from DB storage (i.e. has a PK) but in other contexts it may not yet be in teh DB (has yet to be saved) so just can't retrieve it every time.

The collection that im interested in here is being "double persisted" -- once as the collection SelectedQuestionGroupAssignments persisted in my usercontrol (session or viewstate or whatever), and a second time as the collection belonging to the Evidence (myEvidence.EvidenceQuestionGroupAssignments) which has also been persisted to session.

So i would like to persist the Evidence (myEvidence) so ican use it to create assignements, but not persist myEvidence.EvidenceQuestionGroupAssignments

I might be missing something obvious here but, in the second case, you can persist the Evidence entity alone by not specifying a recursive save. (recurse = true)

Walaa wrote:

So i would like to persist the Evidence (myEvidence) so ican use it to create assignements, but not persist myEvidence.EvidenceQuestionGroupAssignments

I might be missing something obvious here but, in the second case, you can persist the Evidence entity alone by not specifying a recursive save. (recurse = true)

i'm talking about persisting the myEvidence to the session or viewstate in order to conitunethe process of setting up its related fields -- not persist it to the DB.

remember, in the wizard my goal is to set up my entities and persist them to DB only at the end. The entity myEvidence may not have even been persisted to teh DB yet in this (create) scenario so i will not have a PK with which to simply retrieve it an any point in the process.

In the big picture, i am trying to build a system that will both create and edit the myEvidence entity, and save the results when the process (wizard with many complex steps) is complete.

LLBLGen Pro only saves entities which are new or which are changed. So unaltered entities aren't saved, they're ignored. This is transparent for you, so you can for example fetch a collection of entities, let the user alter two of them, add some new ones and and then save the whole collection (and related entities). The runtime will figure out which ones are new, which are altered and in which order they've to be persisted.

Placing entities inside the viewstate will force them to be serialized binary. If you're using adapter, you can make this more efficient by using fast serialization (see documentation under distributed systems to enable fast serialization). This will make the data more compact and the process is much faster. Storing objects in the session doesn't serialize the data, you can store the objects there without problems (unless you're using a session storage inside a db of course).