Future plans - WPF and Silverlight


Author
Message
Edhy Rijo
E
StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)
Group: StrataFrame Users
Posts: 2.4K, Visits: 23K
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

ChanKK
ChanKK
StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)
Group: Forum Members
Posts: 190, Visits: 1.3K
What about LINQ support for BO?
Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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.
ChanKK
ChanKK
StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)
Group: Forum Members
Posts: 190, Visits: 1.3K
Hi
My main reason of LINQ is only for progressive fetching / lazy loading feature as this moment. I hope SF BO can support this with data manipulation feature as well.
For example, data entry is as usual, but data is retrieved on demand.
Charles R Hankey
Charles R Hankey
Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)
Group: Forum Members
Posts: 524, Visits: 30K
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.
ChanKK
ChanKK
StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)
Group: Forum Members
Posts: 190, Visits: 1.3K
Charles R Hankey (3/24/2011)
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.


You opened my mind!!!
thank you for your 2c
ChanKK
ChanKK
StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)StrataFrame User (414 reputation)
Group: Forum Members
Posts: 190, Visits: 1.3K
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.
Charles R Hankey
Charles R Hankey
Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)
Group: Forum Members
Posts: 524, Visits: 30K
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.  

The basis of the MVVM design pattern is that there is no awareness in the View Model of the View ( the WPF UI ).  Ideally there is no code-behind in the WPF.  This means you can test your View Model entirely without UI and you can design UI ( the WPF View ) with something like Expression Blend without knowing anything about the View Model other than what properties it exposes.  

If you consider the design of a winform and its tight coupling with the business layer you can see just how different that is.

And of course the future is entirely in the Entity Framework, so there is a complete rethinking of the data layer.

The good news is that a lot of the code in a winform is just unnecessary in WPF, since the binding model in WPF is so much more sophisticated than in Winforms.  And because SF has always been designed with n-Tier in mind, you probably have the really important business logic referencing the business layer and that means moving it to the view model can be done logically.

But don't have any illusions about the new paradigm.  WPF - MVVM - EF model - SQLServer is a lot more of a head-shift from current SF --Winforms - BO - SQLServer  even than VFP to .NET with Strataframe.

But hey, what doesn't change is the mental horsepower and agility that is not platform dependent Smile  

Trent and Ben and the gang are quite capable of mentally bridging the gap between current design and future design goals.  

My hope is that they find it feasible from a business point of view to put in the incredible amount of work it takes to basically design an entirely new framework and bring to that something that would make SF WPF EF a strong contender in the marketplace by leveraging DDT to work with architectural design structures like Prism and Cinch to deliver value-added for all the people who are familiar with the direction this new ( just becoming really usable in 4.0 ) paradigm is taking and are still looking for help in increasing RAD capabilities and addressing data structure deployment issues to existing data that are handled so well in DDT.  

I think there is room for such a tool, but I don't underestimate the resources and time it would take to create it.


Ger Cannoll
Ger Cannoll
Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)Advanced StrataFrame User (632 reputation)
Group: StrataFrame Users
Posts: 430, Visits: 507
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
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search