SL, WPF, ASP.NET or ASP MVC
-
Guys, I have been coding asp.net for almost 10 years now. I'm just finishing up my first production silver light application. It is a small application that I have spent a 10 days doing what I could have done in ASP.Net in one day. Personally, I like the WPF part of SilverLight an awful lot, but all the asynchronous service calls and magic (generated proxies etc...) to get Silver Light to work is mind boggling. Yes, the UI is a bit quicker than my ASP.Net pages, but the amount of work to make it nice and the amount of hassle to get it working just doesn't seem worth it to me. What do you all think is the best platform to use for corporate LOB applications considering I can pretty much do whatever I want. Oh, I will say this, regardless of what I choose to use in the future, I have learned a shit ton in the last two weeks about how to use events, delegates and Lamda Syntax. Also, I hate the lamda syntax for events. It makes reading code so confusing. I don't mind writing out a few extra lines of code, at least my brain doesn't hurt when I read it.
I didn't get any requirements for the signature
-
Guys, I have been coding asp.net for almost 10 years now. I'm just finishing up my first production silver light application. It is a small application that I have spent a 10 days doing what I could have done in ASP.Net in one day. Personally, I like the WPF part of SilverLight an awful lot, but all the asynchronous service calls and magic (generated proxies etc...) to get Silver Light to work is mind boggling. Yes, the UI is a bit quicker than my ASP.Net pages, but the amount of work to make it nice and the amount of hassle to get it working just doesn't seem worth it to me. What do you all think is the best platform to use for corporate LOB applications considering I can pretty much do whatever I want. Oh, I will say this, regardless of what I choose to use in the future, I have learned a shit ton in the last two weeks about how to use events, delegates and Lamda Syntax. Also, I hate the lamda syntax for events. It makes reading code so confusing. I don't mind writing out a few extra lines of code, at least my brain doesn't hurt when I read it.
I didn't get any requirements for the signature
Well, WPF & Silverlight do have a rather large learning curve. Both also require you to change how you think when you write apps. If you tried to write a Silverlight app in an ASP.Net'ish way, yeah, it would suck. Just as if you tried to write a WPF app in a Winforms/MFC'ish way. Both WPF & Silverlight are designed to be used with the MVVM pattern. If you are using them in the "old school way", you aren't using them right :). Once you master data binding & XAML & triggers & events & control templates & styles, etc., your codebase will shrink by like 50% or more. Lots of things that you had to implement in hackish ways in Winforms / ASP.NET are magically free in WPF / Silverlight. I was recently offered a job by a well known and awesome company, but turned it down because it meant going back to C++ / MFC. No freakin way man! :).
-
Well, WPF & Silverlight do have a rather large learning curve. Both also require you to change how you think when you write apps. If you tried to write a Silverlight app in an ASP.Net'ish way, yeah, it would suck. Just as if you tried to write a WPF app in a Winforms/MFC'ish way. Both WPF & Silverlight are designed to be used with the MVVM pattern. If you are using them in the "old school way", you aren't using them right :). Once you master data binding & XAML & triggers & events & control templates & styles, etc., your codebase will shrink by like 50% or more. Lots of things that you had to implement in hackish ways in Winforms / ASP.NET are magically free in WPF / Silverlight. I was recently offered a job by a well known and awesome company, but turned it down because it meant going back to C++ / MFC. No freakin way man! :).
No, I understand they are nothing like ASP.Net. While I agree the overall code base would shrink, that doesn't help me much. I always get stuff done way to quickly in ASP.Net. I actually don't mind writing a bit more code when it is easier to understand / follow. Also, I think coding the tricky stuff is much more tricky in Silverlight.
I didn't get any requirements for the signature
-
No, I understand they are nothing like ASP.Net. While I agree the overall code base would shrink, that doesn't help me much. I always get stuff done way to quickly in ASP.Net. I actually don't mind writing a bit more code when it is easier to understand / follow. Also, I think coding the tricky stuff is much more tricky in Silverlight.
I didn't get any requirements for the signature
Yeah, some stuff that was super trivial pre-Silverlight / WPF is now overly complicated. Something that took you one line of code in ASP.NET could take several hundred (or more) in Silverlight / WPF. Thats only a few specific areas though IMO. More often the case will be that something that took thousands of lines pre-Silverlight / WPF now takes one line. If you use MVVM, I think you will find your code is amazingly clean and readable. HOWEVER, be warned... MVVM has an initial "start up cost" and learning curve like Silverlight did. By "start up cost", I mean WPF and Silverlight don't give you everything you need to do MVVM out of the box. There are lots of libraries out there that fill in the holes. Anyways... once you get past the initial learning curve of Silverlight & MVVM, the payoffs are huge. Lots of things that are easy in Silverlight / WPF can't even be done otherwise. Once you truly harness the power of data binding, you'll wonder how you ever got along without it. It would certainly behoove you to write a "MyBagOfTricks.dll" type assembly where you stick the "tricky" stuff in generic / reusable ways and take it with you from job to job and build it up over the years.
-
Guys, I have been coding asp.net for almost 10 years now. I'm just finishing up my first production silver light application. It is a small application that I have spent a 10 days doing what I could have done in ASP.Net in one day. Personally, I like the WPF part of SilverLight an awful lot, but all the asynchronous service calls and magic (generated proxies etc...) to get Silver Light to work is mind boggling. Yes, the UI is a bit quicker than my ASP.Net pages, but the amount of work to make it nice and the amount of hassle to get it working just doesn't seem worth it to me. What do you all think is the best platform to use for corporate LOB applications considering I can pretty much do whatever I want. Oh, I will say this, regardless of what I choose to use in the future, I have learned a shit ton in the last two weeks about how to use events, delegates and Lamda Syntax. Also, I hate the lamda syntax for events. It makes reading code so confusing. I don't mind writing out a few extra lines of code, at least my brain doesn't hurt when I read it.
I didn't get any requirements for the signature
This is more a thought for the Lounge than a question though.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it. My latest tip/trick
-
This is more a thought for the Lounge than a question though.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it. My latest tip/trick
Yes, it is.
I didn't get any requirements for the signature
-
Yeah, some stuff that was super trivial pre-Silverlight / WPF is now overly complicated. Something that took you one line of code in ASP.NET could take several hundred (or more) in Silverlight / WPF. Thats only a few specific areas though IMO. More often the case will be that something that took thousands of lines pre-Silverlight / WPF now takes one line. If you use MVVM, I think you will find your code is amazingly clean and readable. HOWEVER, be warned... MVVM has an initial "start up cost" and learning curve like Silverlight did. By "start up cost", I mean WPF and Silverlight don't give you everything you need to do MVVM out of the box. There are lots of libraries out there that fill in the holes. Anyways... once you get past the initial learning curve of Silverlight & MVVM, the payoffs are huge. Lots of things that are easy in Silverlight / WPF can't even be done otherwise. Once you truly harness the power of data binding, you'll wonder how you ever got along without it. It would certainly behoove you to write a "MyBagOfTricks.dll" type assembly where you stick the "tricky" stuff in generic / reusable ways and take it with you from job to job and build it up over the years.
Thanks for replying. I want to harness the power of data binding, but please tell me, how do I debug the binding when the result on the page (or user control) is not what I expect?
I didn't get any requirements for the signature
-
Thanks for replying. I want to harness the power of data binding, but please tell me, how do I debug the binding when the result on the page (or user control) is not what I expect?
I didn't get any requirements for the signature
May I suggest that you use, as the basis of your projects, the library that Marlon Grech and I wrote called MefedMVVM[^]? With it, you can create views in Blend with design time view models. A design time view model is one that displays data in the designer so you can see what your application looks like in a simulated runtime environment while you are actually developing it.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
May I suggest that you use, as the basis of your projects, the library that Marlon Grech and I wrote called MefedMVVM[^]? With it, you can create views in Blend with design time view models. A design time view model is one that displays data in the designer so you can see what your application looks like in a simulated runtime environment while you are actually developing it.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
I'll check it out. Thanks.
I didn't get any requirements for the signature
-
Yeah, some stuff that was super trivial pre-Silverlight / WPF is now overly complicated. Something that took you one line of code in ASP.NET could take several hundred (or more) in Silverlight / WPF. Thats only a few specific areas though IMO. More often the case will be that something that took thousands of lines pre-Silverlight / WPF now takes one line. If you use MVVM, I think you will find your code is amazingly clean and readable. HOWEVER, be warned... MVVM has an initial "start up cost" and learning curve like Silverlight did. By "start up cost", I mean WPF and Silverlight don't give you everything you need to do MVVM out of the box. There are lots of libraries out there that fill in the holes. Anyways... once you get past the initial learning curve of Silverlight & MVVM, the payoffs are huge. Lots of things that are easy in Silverlight / WPF can't even be done otherwise. Once you truly harness the power of data binding, you'll wonder how you ever got along without it. It would certainly behoove you to write a "MyBagOfTricks.dll" type assembly where you stick the "tricky" stuff in generic / reusable ways and take it with you from job to job and build it up over the years.
I just read this rant and I find myself agreeing. Holy shit, adding a button click event and selected index changed event to xaml.cs makes things SO much easier. I don't feel like I am losing anything by doing this. I'm not using any Unit Test, for I have Business Analyst who does real testing via the UI. So, why do I have do I have keep code out of the xaml.cs?
I didn't get any requirements for the signature