Friday, April 15, 2011
Sunday, January 23, 2011
Being declarative when it fits with the Model Driven Framework ECO for Visual Studio 2010
So I always praise this declarative development that Enterprise Core Objects lends itself to. Take the ViewModels – I go on and on, post after post, rambling on how amazingly fast and robust a UI built this way can be delivered.
But what if I want something really special in my UI – something that the ViewModel engine does not support. If I have do abandon the technique then I might as well skip it in the first place some might argue. Point taken. This post is for you.
In the ViewModel – editor above I have marked a little checkbox called “Content override” with red. And I also marked how it is rendered in the preview – like a square that says “OVERRIDE”. This is one way to get “odd” things into the otherwise purely declaratively defined UI.
When a ViewModel column has the “Content Override” set, an event will fire on the ViewModelUserControl (same for Silverlight, WPF, ASP.NET and windows forms), and in this event you can pretty much do want you want with the data provided for that column.
In code it can look something like this:
Note the that Override area is implemented as a Grid in WPF and Silverlight and you can add the things you want to show up here with another user control or what have you. The result of the expression for the column will be in DataContext for that very Grid.
In my case it turned out like this:
Fast, flexible and low maintenance for standard UI – what is not to like?
Sunday, January 16, 2011
Using different WCF Bindings with Enterprise Core Objects – ECO – the model driven framework
There are already numerous ways to set up an Eco-based system. Besides having a multitude of PersistenceMappers that enables Object-relational mapping for the most popular databases – Eco also provides a Bridged communication between an Eco-client and an Eco-server. Since Eco6 this is performed by the EcoPersistenceClientWCF (client) and the EcoPersistenceMapperProviderWCF (server).
What this bridge actually does is to handle all server communication in terms of queries, fetches, lazy loading, updating and refreshing over an xml based format we call DataBlock. Several advantages come from using this client server bridge rather than having the clients hook up with the server based database by itself:
The client does not need to know anything about the database being used – hence no distribution of Client-db-communication-setups.
The server does not need to expose the database for client calls and thus invite attacks from all the suckers out there.
The Server is able to provide you with an efficient Refresh mechanism that easily can be set up to synchronize all the clients.
Since Eco6 the bridge is implemented with WCF – before Eco6 this was implemented with .net Remoting – but WCF is much more flexible and configurable and better in everyway.
Eco creates a BasicHttpBinding if nothing else is configured. This is a quick way to get things going – but of course many situations call for better security, less overhead and/or authentication that is easily achieved with WCF. Maybe you want to create your own binding implementation to solve some business requirement and WCF is good for that too.
I added a sample, EcoProjectWCF_NET_TCP_Binding to show how to configure different bindings than the standard BasicHttpBinding.
The client’s – WCF Settings
The client has an App.Config that can be left empty – but in this sample it looks like this:
It defines a named EndPoint “TheEndPoint”, it defines the binding as netTcpBinding and it has the IPersistenceMapperWCF contract. This Contract is the same for every Eco client server bridge.
Also note the Address that points out the server – we need to make sure that the server is available at that address – server configuration is explained in the next section.
In the EcoSpace, that is shared by the client and the server but nevertheless the place to define the client persistence mapper, we have added the PersistenceMapperWCFClient. In order to use the setting from the App.Config we set the EndpointConfigurationName to the one used in the config : “TheEndPoint”. Done. Client is all set.
When the EndpointConfigurationName is set, the PersistenceMapperWCFClient component ignores the Uri setting. The Uri setting is only there to give an address to the server for the default BasicHttpBinding, also the MaxReceivedMessageSize setting is ignored since this is better defined on the binding in the App/Web.Config.
The server’s – WCF Settings
Also the server has an App.Config – if your server is hosted by IIS then it is a web.config but the content is the same:
This config file defines the Service. The name is important and is unique for each ECO project you create – it is the class of the WCF stub that you will find in the <projectname>PMP.cs file:
The contract in the config endpoint will always be the same: Eco.Wcf.Common.IPersistenceMapperWCF
A good feature is that you can add several endpoints to your service – so that you can have multiple types of clients that communicate in different ways. Silverlight does not support all that many Bindings (not our fault) so Silverlight clients need to talk over http. But if you have in-house clients or ASP.NET servers on the safe side of the firewall you will want something more efficient most likely.
The last thing to configure for the server in this sample is to call Register with an Address:
What about HasUserCode in Enterprise Core Objects – ECO the Model Driven Framework
Class Attributes in classes modeled with ECO has a property called HasUserCode. This post sets out to explain what effect the property has and what the intended use is.
Let us say that we have this model:
Focus the DueDate attribute and look at the Object inspector:
By default the HasUserCode property is false – this says that there are NO side effects or checks applied in code that influence or stop anyone from having the value set.
Let us generate the code:
The Invoice class is implemented as a partial class were Invoice.cs is yours and Invoice.eco.cs is maintained by the Framework.
Open up the Framework owned Invoice.eco.cs and look at the attribute definition:
As you can see there is no room for extravaganza while setting or reading the attribute “DueDate”.
Let us set HasUserCode to true for the DueDate attribute in the model – update the code and look at the Framework owned file again:
Notice the difference. We now have calls to DueDateReading, DueDateRead, DueDateChanging, DueDateChanged.
These are all Partial Methods declared by the framework. Partial method is a .net language construct that is perfect for Frameworks like ECO to use. ECO added these definitions to the Invoice class:
You – as the developer – may need only one or two of these interception points – but ECO gave you all. Unused Partial Methods are however stripped by the compiler and cost you nothing in runtime.
Now we can head back to Invoice.cs – the implementation file that you use and the framework does not touch:
Very empty so far but we can now implement one of the interception points. Just write “partial” and see what comes up:
Pick the one you want and add your stuff:
Why not do this all the time?
The normal question after having explained HasUserCode is “Why would you ever want to turn HasUserCode off?“. It is a relevant question since the partial methods does not cost anything in runtime – we might as well leave the HasUserCode on all the time… Or?
The question is slightly more complex. ECO has the ambition to be as effective as possible and always use the most efficient way to get things done. As a result of this all the internal state of objects is not stored in the frontend object as such but in a centralized cache. This strategy gives us advantages on many levels – like holding object identities before they are fully loaded, knowing what we have loaded or not, signaling changes, ensuring association ends even if not completely loaded, execute models without generated code etc , etc.
So when following expressions for subscriptions – created automatically or explicitly, or expressions from ViewModels, Handles, Constraints or Actions – ECO does not really need to route the call thru the frontend object – it can head straight for the cache and cut a few cpu cycles from the workload – it might not be much but since Eco is a Framework these things add up and become important.
UNLESS the read or written attribute has the HasUserCode flag set – if it has ECO will always route access thru the frontside object.
So does this mean that HasUserCode==true makes my code slower? Technically yes – it will cost you a couple of cpu cycles – so “a lot slower?” No!. You should not worry about that if you need the interception points – but you should leave HasUserCode set to false if you have no intention of using the interception points.