Introducing MicroModels

We want the Func
Give up the Func
We need the Func
Gotta have the Func

Consider this a positive review for MicroModels. Feel free to use it on any promotional materials.

(Blog comments on a Friday afternoon : where musical references and geek collide.)

Nice one Steve, Parliament references! (Or should that be Parliamen<T> ? doubly bad geek humour there)

Paul, could you add in some auto / convention based mapping ? Then it could be even smaller.

@Damian, there's an AllProperties() method to map all properties on an object - e.g.,:

AllProperties(customer);

Instead of:

Property(() => customer.FirstName);
Property(() => customer.LastName);
...

There are also some methods like WithPrefix and Exclude to further change how AllProperties works. Are there other conventions you would like to see?

Nice work. This may come as a shock though: TypeDescriptors don't work in Silverlight. The binding engine is fundamentally different under the covers... Just so you know.

Hi Rob, nothing about anything not working in Silverlight shocks me anymore :)

Love it!

I really like this idea.

What I don't like is that using Expressions is slow, especially when you're initializing a couple of thousand ViewModels to put in a list of some sort.

Could you put the mapping in the static constructor, and pass in the type into the setup?

static EditCustomerModel()
{
    Property<Customer>(customer => customer.FirstName);
    Property<Customer>(customer => customer.LastName).Named("Surname");
    Property<Customer>("FullName", customer => string.Format("{0} {1}", customer.FirstName, customer.LastName));
}

public EditCustomerModel(Customer customer, CustomerRepository customerRepository)
{
    // Still need to define the command on the intance, but since it's not using reflection...
    Command("Save", () => customerRepository.Save(customer));
}

That way the reflection is done once, and cached, speeding up the whole process.

Awesome - but a shame it doesn't work in Silverlight.

MicroModel would be useful in many cases and would compliment many MVVM designs/frameworks well. Having the AllProperties call + a Command would be enough VM in many cases. If MicroModel becomes - well - too Micro you could always write the more complicated models by hand, or just add tradition properties to the class deriving from MicroModel.

Heck yes! I started to do something like this some time ago and was told that it wasn't possible. I had just started looking at TypeDescriptor when I decided to try something else instead. While I didn't write it, I feel vindicated that it is possible and even elegant! The comments about Silverlight remind me that was the reason I finally gave up.

@Cameron - You don't need the static constructor for each micro-model implementation. A better solution might be a common, static cache in the MicroModel base class. Then, no matter how many times you assign it, you could look up the type and expression from a Dictionary and return the cached mapping. That would begin to approximate how the DLR caches its calls, I believe. Of course, we are now getting to the point where we should begin asking why we don't just use something like IronRuby or IronPython, which are supposed to be allowed to bind in Silverlight 4, iirc.

@Ryan - That's what I was thinking of, caching the definition in a dictionary. I was just doing it in the static constructor to avoid threading issues. But the issue with that is how does the definition get the instance information. Currently Pauls solution is using closures to capture the instance, which means each definition is different for each model.

Anyway, it's the lambda being assigned to an Expression object that takes the time. If the lambda is assigned to a delegate it's fine. So you want to avoid doing lambda assignments to Expressions as much as possible. I've found them slower than straight reflection.

I fully agree that a lot of MVVM "frameworks" put too much into the ViewModel.

A question about your MicroModels: As far as I understand, using MicroModels results in a direct coupling (through binding) from the view to the DOM (instance of Customer in your example) - meaning that everytime the user modifies data and data binding kicks in, the DOM is updated?

Or am I missing something?

Cheers Urs

Hi all,

I was able to port this great library to Silveright. You can find more information here.

Really nice!

I use Caliburn, so I changed my ViewModel base class to extend MicroModel instead of Presenter and then changed MicroModel source code to make MicroModelBase extend Presenter.

It worked for me. Now I have MicroModel and Caliburn working together.

Paul,

I like this idea.

It seems everyone is trying to solve the same problems with object mapping/transform/binding.

What are your thoughts on bi-directional transforms? From quickly looking over your code my assumption is that the transforms for the non-simple properties is one-way?

It still feels like there must be a more elegant way to do this mapping/transformation. DSL with a visual tool? Compiler support? etc

It seems to me everything is pointing in the direction of a generic object mapping/transformation framework...

Yes there is AutoMapper but this is not "Live". There is WPF Binding but this is no good for POCO. There are various CLINQ style derivatives for mapping/transforming collections, but they are one-way by their nature.

Jack

I'm probably missing something, but the Property method is protected, so the "Collection().Each((x,model) => model.Property...)" doesn't work.

Do I have the wrong bits?

The Create method, in the PropertyReaderFactory:

public static IPropertyReader<TCast> Create<TCast>(Type objectType, string propertyName)

fails if the intended property is overrided. I fixed by doing:

//Try to find the property at the declared type level
var propertyInfo = objectType.GetProperty(
    propertyName,
    BindingFlags.Instance |
    BindingFlags.NonPublic |
    BindingFlags.Public |
    BindingFlags.DeclaredOnly
);

//If could not find at the declared type level, look in the base types
propertyInfo = propertyInfo ?? objectType.GetProperty(
    propertyName, 
    BindingFlags.Instance | 
    BindingFlags.NonPublic | 
    BindingFlags.Public
);

Regards,

Rafael Romão

Well, I WAS missing something, Property() is both a method on the MicroModel class AND an extension method on the IMicroModel interface, and I wasn't importing the namespace of the ext. method. I only noticed today that the source code is available :) (weird?)

Paul,

I'm trying to track down something - does MicroModels presume that the source objects (dto's, business objects, etc) that your Models reference are themselves observable things (i.e. they need to implement INotifyPropertyChanged)? Is there a way that the Models can be observable independent of the dto/data/business layer? Is there a difference in observability between explicit properties (lambda or otherwise), and implicit properties (AllProperties)? It seems that the AllProperties route always uses ReflectPropertyDescriptors as the bottom layer and preclude some kind of notification mechanism. I'm working in a project where the DTO's come from WCF and are simple datacontract objects.

Thanks

RobC

Hey Paul,

Just came across this and it looks really cool! I'm actually working on something very similar, perhaps there is some crossover / collaboration we could do? Take a look at my library on codeplex and let me know what you think!

Cheers,

Robert

I'm a bit concerned about the performance loss, yet the way you define objects is simply briliant. Perhaps a similar approach using a DSL will worth some researching; write the code generic using a custom language, and let the "framework" generate the specific code.

The examples and library seem to favour a "model first" approach to MVVM, whereby the model is already loaded before the VM is constructed.

If that is the case how do you handle things like "loading..." screens?

Hi Jack,

i had a similar question because how i've implemented my viewmodels they get their data after they've been constructed and adding the properties after the construction of the viewmodel results in an error because the modelBase is "sealed". Now I add the properties in the constructor with a dummy object and change the object later in the process and call "RaisePropertyChanged" for each property. For that I also added a new method to "Modelbase" which simply iterates all properties and calls automatically the RaisPropertyChanged method.

Her my example:

public class PersonViewModel : MicroModel
{
    private Person _person;

    int i = 1;
    public PersonViewModel()
    {
        Property(() => _person.FirstName);
        Property(() => _person.LastName);

        Command("ClickCommand", () => SetPerson(new Person { FirstName = "Max" + i++, LastName = "Mustermann" }));
    }

    internal void SetPerson(Person person)
    {
        _person = person;

        RaiseAllPropertiesChanged();
    }
}

And the new method in ModelBase looks like that:

public void RaiseAllPropertiesChanged()
{
    foreach (var property in _properties)
    {
        RaisePropertyChanged(property.Name);
    }
}

And by the way: Great tool you've created here Paul!

Is MicroModels still available for download anywhere? Can't seem to find a valid link...

Download link is broken! Please fix it so I can investigate source code of this interesting library. Thank you!

For anyone interested, this project is hosted on Codeplex.

You can found it here.

@Rob Cecil

If your business objects are not observable, perhaps you want to look at a hybrid solution with UpdateControls which appears to do what you're describing.