There are many ways to set up persistence in an ECO based system:
1. You have many different persistencemappers to chose from
– PersistenceMappers for different flavors of relational databases; SQLServer, MySql, Oracle, Bdp, Blackfish, Dbx, Firebird, Mimer, Nexus, SqlLite, Nexus
– PersistenceMapper for save in Xml file
– MemoryPersistence mapper intended for unit testing code
– Option to build your own persistence mapper
2. You can use a persistence mapper from the client directly or you can use a PersistenceMapperClient that calls a Persistence server that in turn uses a persistence mapper for a database or xml-file
3. You can choose to support Synchronization or not. Synchronization is the ability to efficiently discover update needs in client object caches, so that a fetch of objects that has been updated by other clients can be triggered.
4. If you choose to use a Persistence server you have several options on how to implement this:
– As a windows forms application
– As a Windows Service
– As an IIS hosted WCF Service
Choices, choices… Well what is the recommendation? The political correct answer is “it depends” but my personal recommendation is:
Use an IIS hosted WCF Service: This is easy to debug and deploy, IIS is a proven platform that is robust and recovers after failures, it handles load very well and is easy for anyone to supervise. You should use a Persistence server so that you avoid sending sql traffic over the net – better to send the ECO WCF channel that you can configure to use a crypto if needed – or plain http or https if you need it to go thru company firewalls.
As a PersistenceMapper I recommend that you use conditional defines in your code to allow for a XMLPMapper for fast and lightweight development and test, and SQLServer for debugging and production. (Why not MySql or Oracle or something else – no reason– my personal favorite is SQLServer and SQLExpress ).
So why do I recommend to use a XMLPersistenceMapper for fast debug? The answer has to do with the model – the model is the definition that defines what data you can store. In a SQL-Database you need to have a schema that is designed for this model. ECO does this for you in matter of seconds so that is not a big issue. But then you have the constant changes in the model that happens as an effect of your developing work. So you need to tune the SQL Schema to reflect this. Well ECO does this for you as well with DatabaseEvolution – also in matter of seconds. So why not use the SQL-database for development all the time? Why bother with an XMLPersistenceMapper? Well – the development loop should be kept as tight as possible – if you need to “waste” a few seconds for each lap in the development loop (think-do-compile-test) to evolve the database, the neurons in your brain will fade a tiny bit (or whatever they do) making it harder for you to keep your flow and also the chances that someone comes in the room with a Giant-Context-Switching-Issue is always linear to time – these are the main reasons I recommend that you develop with a XMLPersistenceMapper – a few seconds faster… That is all.
Then of course there are many aspects to development were this reasoning does not hold – debugging against real data requires a database, finding and fixing load/save bottlenecks also requires a database. I also have not considered the cost of different components when giving my recommendations, after all IIS and SQLServer are licensed products, and if you are running on a slim budget you may want to tweak my recommendation to something else.
How we set up communication through WFC between Client and Server
On the client side we do this:
1. The EcoSpace Assembly (1) is shared for all client types – except the Silverlight Client that has its own EcoSpace – but has the same function and purpose. In the EcoSpace Assembly we have the EcoSpaceType for this project (2) defined. The EcoSpaceType has a Designer, and on this Designer we add a PersistenceMapperClient (3), In this PersistenceMapperClient we give the Uri to where our server is (4) http://localhost:12345/EcoSolutionShowcasePMPWCF.svc for development.
We also need to connect the PersistenceMapperClient to the EcoSpaceType; click the EcoSpace designer and look in the properties window:
On the server side we use a WebProject (1), and in this we have a new ECO component called a PersistenceMapperProvider or PMP for short (2). The project reference the same EcoSpaceType as the Clients use – and we assign the EcoSpaceType to the EcoSpaceType-property of the PMP (3).
We have also added some PersistenceMappers (4,5) on the PMP design surface. We can only use one PersistneceMapper at a time and we assign one of them to the PMP-type (7).
We also want our Persistence Server to offer the Synchronization ability – so we add the SyncHandler (6) and this connected to the PersistenceMappers (4,5) in the SyncHandler-property.
The actual WCF Service Address is created from knowing the position of the server (it is different if hosted in a virtual directory in IIS, or if we use the development server) and appending the ServiceTypeName in this case EcoSolutionShowcasePMPWCF.svc.
WCF specific settings can be defined in both client and server. You need to do matching changes of course in the clients and server. This is how our servers web.config looks like for controlling the WCF settings:
<system.serviceModel> <services> <service name="EcoSolutionShowcase.EcoSolutionShowcasePMPWCF" behaviorConfiguration="EcoSolutionShowcase.EcoSolutionShowcasePMPWCFBehavior"> <!-- Service Endpoints --> <endpoint address="" binding="basicHttpBinding" contract="Eco.Wcf.Common.IPersistenceMapperWCF"> <!-- Upon deployment, the following identity element should be removed or replaced to reflect the identity under which the deployed service runs. If removed, WCF will infer an appropriate identity automatically. --> <identity> <dns value="localhost"/> </identity> </endpoint> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> </services> <behaviors> <serviceBehaviors> <behavior name="EcoSolutionShowcase.EcoSolutionShowcasePMPWCFBehavior"> <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment --> <serviceMetadata httpGetEnabled="true"/> <!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information --> <serviceDebug includeExceptionDetailInFaults="false"/> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> <!-- Uncomment and set Filepath to trace WCF communication <system.diagnostics> <sources> <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true"> <listeners> <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData= "c:\temp\WCFTracelog.log" /> </listeners> </source> </sources> </system.diagnostics> -->
The settings above comes straight from the EcoSolutionWizard and it uses the basicHttpBinding. The simplest possible set up on the CLIENT side also uses the basicHttpBinding – if you are happy with this – then the client need no additional web.config/app.config settings. If you want to change channels you must change both SERVER and CLIENT’s config files. The changes are not ECO specific – just read up on WCF – or google and copy depending how much you want to know vs how much you want to move on.
In the code I set up some conditional defines:
public EcoSolutionShowcasePMP() : base() { this.InitializeComponent(); // IMPORTANT CONFIGURATION SETTINGS START #if DEBUG_DEVSERVER // I choose to use DevServer and an XML file for persistence for shortest development loop PersistenceMapper = persistenceMapperXml1; persistenceMapperXml1.FileName = @"Data.xml"; #endif #if DEBUG_IIS // ... then I use SQLServer and IIS for a bit more real life debugging/development persistenceMapperSqlServer1.ConnectionString = "Data Source=localhost;Initial Catalog=EcoShowcase;Integrated Security=True"; PersistenceMapper = persistenceMapperSqlServer1; #endif // IMPORTANT CONFIGURATION SETTINGS END }
Selecting packages
A model can be divided into multiple packages. The reason for doing so is really entirely up to you – but it is an important ability to segment a large model or reuse model packages in different applications. You chose packages by clicking the Select Package tool in the EcoSpaceType-designer:
Generating a database script for the first time, or replacing the script completely
You generate the database script by clicking the Generate Schema tool in the PMP-designer. Mind you that you need to have set a PersistenceMapper that supports this operation in the PMP first, you also need to set a valid connection string in the PersistenceMapper:
As you may notice amongst the tables above – they all have names resembling the classes in the model – except for a few that ECO adds by itself. Some administrative tables fill an important purpose to store enough meta data in the database so that ECO can offer to Evolve a database based on one model version to another database that supports another model version. This is a very popular, important and sought after function in a model driven framework.
Evolve the database once the model has changed
I add the Attribute Phone to the CoWorker class, Update the code, then Build the project so that the new code and model is in effect, then press the Evolve Databasetool in the PMP.
And the Phone column was added and new meta information written to database so that we are prepared for another loop on the developing treadmill.
Of course you can do multiple changes, you can add and delete classes, associations and attributes – but take care – dropping stuff in model will drop stuff in database. You should backup if you would kill yourself if something went wrong.
It is not unlikely that your server will stay the way it is now for ever. Since everything is generic and model driven there is little need to change it once you are happy with it. You will of course come back and use the Database Evolve Schema tool – all the time.
Most the things described here are left untouched straight from the ECOSolutionWizard. Just Click and Go.