none
Desktop App file document RRS feed

  • Question

  • I am creating a desktop application in which the user saves the state into an individual file similar to what is done in Microsoft Excel or PowerPoint.  One option is to do this using Binary and XML serialization.  However, I was wondering if the current recommendation is to use SQL CE and entity framework to save the application state.  If the later is the recommendation, then how do I go about creating the database SQL CE file database using code first.  In particular, how do you do this when your allowing plugins via MEF.  How does EF create the file?  I have seen some users use code first in which they create a project that has all the entities in one dBContext to create the initial database file, even though the application may use many dBContext's.  I can see how you do this one time, but how do you do this on the fly many times in order to save the application state into individual files? 
    Monday, May 12, 2014 1:31 AM

Answers

  • A couple of years ago, I had to create an ASP.NET solution that was using n-tier of ASP.NET Web forms. MVP Model View Presenter, WCF Web service layer and with BLL, DAL and EF sitting behind the WCF service.

    A humungous session DTO session object with many object graphs being held within the object that was being used at the UI being keep in state. It was being kept in state to the point that this huge session object was being persisted to the database by use of XML serialization and sending the object on a async thread to be persisted on page-unloads. So a user on a session time out would not lose any information.

    If the solution timed-out, the user walked from the solution and left the Web page on the screen, the user went to the moon, came back to the workstation and continued working on the page, the session object was retrived from the database using EF, deserilized the object and put it back into session as if no session timeout ever occurred. The user continued their work like nothing ever happened.

    There was one table in the database and on the EF model called ObjSesstionState where multiple versions of a the object per user credentials were kept. The last object saved for the user was pulled out of the table on session timeout,  and the object was put back into session. The state table was pruned every two weeks to get rid of dead user session objects.

    So what you are talking about can be done, but it was using the EF database first approach.

       

    Monday, May 12, 2014 2:10 AM