Just reading all the stuff out there now since MS announced plans for Win 8 and tablets etc.... lots of people suggesting that Microsoft will not really be 'enhancing' Silverlight or WPF or even Dot Net ?, and that most development in the future is going to go the way of HTML5 ...Wondering how all this will affect Strataframe

The Microfour team is a collection of some of the brightest guys I know, but I think it is unrealistic to think they are going to be able to move you "with minimum changes" from a winforms - BO based on datasets design to WPF - MVVM - Entity Framework.  

Basically we are looking into MVVC pattern now. If SF can support and auto "move" us to this model/pattern with minimal changes, this would be great. It would dramatically enhance our architecture.

I don't think there is much future in building anything using Linq to Sql.  Linq to Entities is the future and that sort of requires ... entities.

WPF right now is all about the Entity Framework, the MVVM pattern and a very decoupled model using IOC and DI. 

As Trent said, with WPF it is pretty much all or nothing so I'd be very surprised if a future version of SF looked a whole lot like the current SF. 

SF / Winforms right now is about the perfect package for the technologies it addresses.  Personally, I'd like to see the same smarts that went into developing that go into a new DDT working with the Entity Model and then model layer for business logic coupled with easy generation of View Models. 

The magic SF provides in controls would be really unnecessary in a WPF implementation, attention could be given to developing on the MVVM pattern and genereting tests. 

IOW, I don't see a WPF version of SF being backward compatible with SF Winforms.  The paradigms of good design in Winforms / Datasets vs WPF/EF are just too different.  At best, migration of the data structures from the DDT and good documentation on best practices for migrating business layer logic would be wonderful.

I'd like to see something that starts with all the good smo stuff in DDT and uses T4 to build model and view model framework and test classes.  IMO, DDT is the big competitive edge if leveraged properly.  The weakest part of EF right now is putting EDMX changes correctly back into the storage model, but if DDT could pick up those changes and incorporate them into the pkg ...

Just my 2c with no inside knowledge whatsoever of what Microfour has planned or how far along they are.

Hi

All new development in our company is in C#, but that doesn't mean that you need to move to C#.  We have chosen C# over VB.NET for a couple of reasons, but one of the biggest reasons is due to the horrible design-time compiler that crashes all the time on large projects.  This consumes an enormous amount of energy and time trying to get things to avoid the pitfalls of the design-time compiler.  Secondly, VB.NET does some automatic wiring that we generally like to have a little bit more control over in C#.  An example of this is event wiring and handlers.  C# is more nimble in this area.  You can work around this in VB.NET in many cases though. 

But just because the framework is written in C# doesn't mean that you need to swap.  As for WPF, yes, the entire world will have to move in that direct over time.  It is not being very well accepted by application developers are a whole.  It has been quickly adopted by people who deal with more graphics intensive applications.  We have recently written a very complex charting environment that is extremely graphics intensive.  However, since the rest of our application was in WinForms, we had to write this in GDI+ instead of WPF.  WPF doesn't play very nice with WinForms.  There is a control that lets you run WinForm code within a WPF application, but the best example of how this works in when taking a WebBrowser control in a WinForms environment and then trying to make the two work together seamlessly as though there were no web environment in the mix.

So if you are going to go WPF, it should be all or nothing.

You can use LINQ now, though we do no have core functionality for LINQ.  To be honest, we have not 100% decided if we will rely on link at any core level.  It is very slow and has a lot of overhead.  The largest the data set, the slower it becomes.  The principal of LINQ is awesome, but in the end, we are developing real-world applications and the performance has to be there.

What about LINQ support for BO?

Hi Trent,

I agree WPF should be the way to go with SF, this will allow us to move forward the win form world.  Entity Framework has become very popular and from what I hear, very stable.

On a second note, just to re-assure,  all new SF source will be done on C#?  if so, should we (the VB guys) start moving to C#?

Edhy Rijo

Hi Trent -