Would this architecture strategy work for a business application written in F#?

Question

I've been considering how you would write a business application in only F# with WPF. Here's my thinking of a general outline of how to go about it, but I'm looking for whether or not it will work:

1. Start with ADO.NET Entities to automatically generate a data access layer.
2. Since F# doesn't support partial classes, use F# Extension Methods to create a BLL that extends the entity objects with extra members (these will have to mutate the entities)
3. Instead of writing explicit ViewModels, write F# functions that build ViewModel objects on the fly using object expressions.
4. Write an F# function that uses Active Patterns and Decision Trees to build WPF Views on the fly, given ViewModel objects as input. It would also take care of setting up bindings between the View and ViewModel objects.

So, opening a form or page would involve executing a function to generate a ViewModel object instance, and then passing that to the function that builds a View from the ViewModel, and then setting that as the content of your Window. From that point on, it executes in a normal "mutable" MVVM way.

My knowledge of F# is still limited, so I may be going down the wrong rabbit hole here.

Question(s):

• Will this work (in general), or not?
• Is there a better way that you know of?

Answer 1

This should work (tho I'm not sure about mutable entities, as I'm not an F# expert).

But my concern is the performance: F# uses a lot of recursion, especially in the case of decision trees, that will be a lot of work at runtime. I would consider pre-generating everything or a caching system. It's okay to generate at runtime using meta-programming, but why doing it every time when you can do it only once?

Answer 2

I don't know much about ADO.NET entities, or MVVM, or WPF, so I can't offer much critique of the technical ideas personally. It sounds like you have experience with all those technologies and know what's going on there. So my only commentary is that it sounds like there are too many new things to try all at once. To mitigate risks and increase the chance of success, I'd stage this across a few projects. E.g. maybe start with a traditional data layer using existing tools, and just try out your ideas for the F# View & ViewModel. And once you've worked out the kinks and gotten more comfortable with F#, then try tackling the data layer.

Do also be aware of

http://blogs.msdn.com/b/dsyme/archive/2010/07/29/some-f-project-templates-available-online.aspx

which include e.g. MVVM starter templates for F#, in case they provide any ideas/value (I am unclear how much your strategy departs from tradition to know if this will be helpful).

Here's another random link that may or may not be valuable:

http://stackoverflow.com/questions/3085034/f-and-ado-net-idiomatic-f