The future of winforms?

davetherave2

davetherave2

davetherave2

Soldato
Joined
27 Mar 2003
Posts
2,710
So as a general "jack of all trades c# developer" I am finding that the shift to try and mimic the ease of winforms into the web sphere is causing me concern. I am not sure if it is just me being out of touch but the trend obviously over the past 12 months+ has been to develop web or "App" style solutions that are now compatible with multiple platforms mainly mobile/touch screen.

I'm just wondering if core business management solutions which require multiple forms/points of information on the screen can be successfully converted into this style of application.

So I guess what I am trying to get at is it worth continuing developing my skills in winforms or ditch it and look at the likes of winRT or even shift over to WPF or is this as dead as winforms appears to be going.

The reason I ask is due to working on a past project that looked to convert an existing complex winforms management system into a web application failed miserably. This failure was down to a number of issues but effectively the requirement was to replicate what the win forms app did in the webforms which didn't work was cluncky, slow and i felt the new product was crippled by not playing to the strengths of the web forms environment.

If anyone can point in the direction of some good articles for the pro's/con's of win forms in this touch screen obsessed world we have these days it would be great.
 
My advice; forget winforms and webforms.

If you want to do web stuff learn MVC 3/4, if you want to do windows apps learn WPF, javascript and HTML5 - although WPFs time seems limited too.
 
Thanks for the info. Kind of what I was expecting really. It's such a shame to leave these skills behind in many respects, although I do enjoy the challange of learning something new it is a shame but like everything technology moves on.

Although I have some great projects I want to convert to the likes of MVC I fear the main product I support will have to be a rework from the ground up (truth be told it was always going to be if I get my way). I guess I can see where my boss was coming from with trying to "webify" this product. Oh well at least it keeps me busy :)

I have the following books arriving from Santa to help me:

Dependency Injection in .NET by Mark Seemann
The Art of Unit Testing: with Examples in .NET by Roy Osherove
HTML5 Programming for ASP.NET Developers by Bipin Joshi
HTML & CSS: Design and Build Web Sites by Jon Duckett

I already have Pro ASP.NET MVC 3 Framework 3rd Edition by Adam Freeman & Steven Sanderson

I just need to put some serious study time in to understand the concepts of MVC a little more.

I am just wondering if I should also be throwing EF in at the same time or leave that for another day and conitnue to use my current Data Access knowledge and libraries I have set up.

I just need to find some good books on JQuery and Javascript to aid with my knowledge. I am sure the HTML 5 book will help fill in a lot of gaps.
 
Last edited:
If you already know ASP.Net then it shouldn't take you long to get your head around MVC. It really is about the best thing you can do on a time/benefit basis.

With regard to EF, be aware that it doesn't scale very well. At all. We had major bottlenecks with it on a mid-size application (50-100 concurrent users on a 4Gb MSSQL database) which required junking EF completely. We ended up writing our own data access layer, but I hear things like Fluent NHibernate are a very good ORM alternative.

Finally, save your money on a jQuery book. Familiarise yourself with http://api.jquery.com and practise on http://jsfiddle.net instead :)
 
WinForms will always have a place, albeit a legacy one. Unlike WebForms that has been wholly superseded by ASP.NET MVC, Nancy etc.

Forget Silverlight and WPF.

I would also avoid XAML as well. I think its days are also numbered. Nobody likes its incredibly verbose syntax.

Learn MVC and Nancy (a very good, clean implementation of MVC). Learn JS, if you must. Learn HTML5. Learn Metro HTML5 apps using JS only for the purposes of WinMD interfacing with a .NET backend.

Please remember that MVC is in no way perfect. It's still quite crap. It's just far better than the old ASP.NET WebForms way of doing things via post backs, session state and cookies. If you want to see an elegant way to design web apps take a look at WebSharper or Lift.
 
Last edited:
NathanE - If websharper and lift are RAD toolkits then I am currently using Telerik's which I have found brilliant for winforms and webforms alike.

They also have some brilliant coding tools equal to the likes or resharper. I have to look more into their ORM solution as it seems that may scale as required (in the EF world) to the level I need. Current database size for the main app I work with is 24GB and has around 100 - 200 concurrent users on an average day.

Spunkey - I have looked at jquery's website and although it has helped me understand some of the fundementals of the api I find it much easier to have a book in front of me where I can understand the subject matter in a little more depth with examples rather than some basic overview. Plus if there is something I don't quite understand I can flick between pages/sections as required.

At least I have a few weeks off now over christmas I can make a start on some the design principles and finally try to get my head around doing Test Driven Development rather than just go in blind and then fixing errors as I go along.
 
Spunkey said:
With regard to EF, be aware that it doesn't scale very well. At all. We had major bottlenecks with it on a mid-size application (50-100 concurrent users on a 4Gb MSSQL database) which required junking EF completely. We ended up writing our own data access layer, but I hear things like Fluent NHibernate are a very good ORM alternative.
Click to expand...

You have to be very careful with nHibernate as well, it's a complex beast and has terrible performance in certain situations. We're in the process of ripping it out of any query only style calls and replacing it with dapper. I'd love to rip it out of crud as well but it'll take a while to do.

One of our juniors made some code which pulled 160k rows from a simple lookup style table and queried against it. They set this up to use nHibernates cache so it wasn't hitting the DB each time but it was still initializing 160k nHibernate tracked objects :o Our appPool for this site on a triple server farm 24 core 24gb ram machine went from averaging 2GB to 4.5-5GB and the GC went in to meltdown, never seen such crazy numbers in performance monitor. CPU jumped from about 5% for this appPool to 15-20% as well. A fairly simple mistake from a junior which slipped through code reviews and destroyed the sites performance until we did an emergency release.

nHibernate instantiates a lot of classes on it's own to manage entity tracking etc which all need to go through the GC.
 
EF is better than NHibernate. NH is a horrible framework. It's a hacky and ghastly port of a legacy Java project.

All ORMs are nasty and should only be used as a last resort. There are better ways of doing things, see DDD, CQRS and ES. There's always NoSQL as well, look at RavenDB. Don't touch MongoDB, it's crap and broken. Also avoid Redis (which is a KV store, not a document database like Raven) as this too is broken, use Riak which is just Redis "done right".
 
Last edited:
NathanE said:
EF is better than NHibernate. NH is a horrible framework. It's a hacky and ghastly port of a legacy Java project.

All ORMs are nasty and should only be used as a last resort. There are better ways of doing things, see DDD, CQRS and ES. There's always NoSQL as well, look at RavenDB. Don't touch MongoDB, it's crap and broken. Also avoid Redis (which is a KV store, not a document database like Raven) as this too is broken, use Riak which is just Redis "done right".
Click to expand...

Redis is solid and much used. I'd like to know your use-case that made you consider it to be "broken".

Same for MongoDB tbh. I can't say I've ever had a problem with it.
 
DanF said:
lol recommending RavenDB :o And bashing Redis, nice.
Click to expand...

Redis is more comparable to Memcached. It's an in-memory "database" which means it's limited by how much memory you have in your server. See http://redis.io/topics/virtual-memory. Riak has no such flaw because they put a lot of effort into getting their data structures right, see Bitcask.

RavenDB is very popular in the .NET space. It's a well designed implementation of a document store. It has a brilliantly clean LINQ based API.
 
BahBah said:
Redis is solid and much used. I'd like to know your use-case that made you consider it to be "broken".

Same for MongoDB tbh. I can't say I've ever had a problem with it.
Click to expand...

You have low standards. Choosing the correct tooling is one of the key responsibilities of taking the lead role on a software project.

See above why I'd never use Redis over say Memcached or Riak.

I thought everybody knew that Mongo isn't an ACID database, but seems not. See http://stackoverflow.com/questions/3736533/why-doesnt-mongodb-use-fsync By foregoing ACID they made it fast but most projects don't need to save .01sec and throw away data integrity in the process.
 
Last edited:
Excuse my ignorance here but these products you are going on about where do they sit in the grand scheme of things. Are they ORM systems that tie into a sql product like MS SQL or are they designed to replace these.

We are going to be investing in SQL 2012 shortly to replace our aging SQL 2000/2005 so we will be using 2012 DB and Reporting services (I hope these have been improved since 2005)
 
NathanE said:
Redis is more comparable to Memcached. It's an in-memory "database" which means it's limited by how much memory you have in your server. See http://redis.io/topics/virtual-memory. Riak has no such flaw because they put a lot of effort into getting their data structures right, see Bitcask.

RavenDB is very popular in the .NET space. It's a well designed implementation of a document store. It has a brilliantly clean LINQ based API.
Click to expand...

Um you might want to go and do some homework before making comments like this. Redis is a very reliable and powerful system when used right, true trying to use it as a massive as in out of main memory KV store isn't one of it's main strengths ;) but it was never advertised like that. It has several benefits over Riak and several negatives, tbh you'd be able to use them in the same system in a complementary way if you wished.

RavenDB, well hohum have you actually used it or tried it out in any project or are you just reading about it? It's base tech is to store entities in to ESENT which is a free storage mechanism built in to windows only. It then makes up lucene indexes for you as you use it to get querying and performance. There's an obvious lag between inserting an entity and it being available in the lucene index for querying which you pretty much don't get in any other product. If you have devs which know their job then you might as well store your data in something worth storing it in like SQL and just spin up your own lucene indexes where it makes sense. The you get full reporting, backup, easy management etc that everyone is used to. It also costs a lot of money compared to pretty much all the other noSQL stuff which is generally free even though it's also based on free tech itself.
 
Last edited:
davetherave2 said:
Excuse my ignorance here but these products you are going on about where do they sit in the grand scheme of things. Are they ORM systems that tie into a sql product like MS SQL or are they designed to replace these.

We are going to be investing in SQL 2012 shortly to replace our aging SQL 2000/2005 so we will be using 2012 DB and Reporting services (I hope these have been improved since 2005)
Click to expand...

Yeah some of them are, EF (entity framework) is made by MS and is a big fully featured ORM you'd use in .net code. nHibernate is similar but it started off as a port from a java project so it's a bit weird to use. A few years ago though EF was trash and nHibernate was pretty much the only kid on the block but it's now changed and you'd probably want to use EF if it works for you.

Personally I'd recommend just using a microORM instead if you can, they just help you map data from sql queries back in to your objects. You just use t-sql or sprocs to use them so there's pretty much no performance hit unlike the full fat ORM's which can have terrible performance in certain situations.

There's a pretty big jump in performance from sql 2005 to 2012, our DBA's love it.
 
DanF said:
Um you might want to go and do some homework before making comments like this. Redis is a very reliable and powerful system when used right, true trying to use it as a massive as in out of main memory KV store isn't one of it's main strengths ;) but it was never advertised like that. It has several benefits over Riak and several negatives, tbh you'd be able to use them in the same system in a complementary way if you wished.
Click to expand...
Do homework on what? I think I already have. It sounds like you were caught off guard and didn't actually realise Redis is as limited as it is. Most people don't either, so don't be embarrassed by that. Every day people adopt systems like this under the assumption they behave in certain ways but only realise when it is too late that they in fact don't. And thus yet another flawed, unmaintainable mess of a business system is born.

I didn't say Redis isn't reliable, I'd be horrified if it wasn't. What I said was that it's a flawed system because it can only scale up to how much RAM you can throw at it. Why adopt such a system when better alternatives exist? Can you imagine if SQL Server had this limitation? People would be outraged - so why treat Redis any different?

By the way there was a period when Redis *was* being advertised as a memory scalable system. But they *removed* that feature because it hurt performance so much. They had a flawed implementation that merely relied on the OS's virtual memory manager to do all their work for them which was grossly inefficient. They couldn't be bothered to actually redesign their system to use a LSM-tree data structures like Riak. So yes, I think you are lacking some history on the Redis project. You can get started here:

https://groups.google.com/forum/?fromgroups=#!topic/redis-db/dDQMu_oeyAs

and here:

https://groups.google.com/forum/?fromgroups=#!topic/redis-db/gj1yUzXGamk

RavenDB, well hohum have you actually used it or tried it out in any project or are you just reading about it? It's base tech is to store entities in to ESENT which is a free storage mechanism built in to windows only. It then makes up lucene indexes for you as you use it to get querying and performance. There's an obvious lag between inserting an entity and it being available in the lucene index for querying which you pretty much don't get in any other product. If you have devs which know their job then you might as well store your data in something worth storing it in like SQL and just spin up your own lucene indexes where it makes sense. The you get full reporting, backup, easy management etc that everyone is used to. It also costs a lot of money compared to pretty much all the other noSQL stuff which is generally free even though it's also based on free tech itself.
Click to expand...
Sure it's not "free" but who cares? Most good things in life aren't free. Your wild opinions on RavenDB are contrary to the majority in the .NET space.

The "obvious lag" that you refer to with regard to updating the full-text search indexes is actually called *eventual consistency* and this is a prerequisite in building high-scalability, low transactional and highly available systems that are so common in the NoSQL space.

By the way I only said "look at RavenDB" to the OP as quite frankly it was the first decent one that popped into my head. By no means am I "recommending" it to the OP over all the others. There are LOTS of good document store databases out there, of which RavenDB is just one. It is arguably the best one for .NET projects because of its excellent LINQ integration. But that may or may not be important to the OP.


I really hope you aren't leading software projects yet as you come across in all the wrong ways. If this were an interview for such a position I'd have said no.
 
Unfortunately the same goes to you Nathan. But carry on with the personal insults, everyone loves them.

If you really don't understand how you'd be able to use Redis in a good way then I'm not sure what your doing in technology (hah there, see what I did).
 
Chill out idiots eh?

Talk about "thread hijack"

OP you need to get into web - the desktop is dead, mate - the closest thing to it these days with a future is native mobile. Learn both - then you're sorted for the next few years.

Its all web/mobile with cloud now
 
You must log in or register to reply here.
Back
Top Bottom