ASP Forms vs. MVC 5

[GreggThelen]

I'd like to get some pros/cons of ASP Forms vs. MVC 5. This would be for ease of use and maintenance when using CSLA.

I'd like to begin porting business applications over to the web and I'd like to get some insight from people who've used CSLA with these technologies. For me the issue is that I like what I've seen in MVC but having been recently burned by Microsoft's handling of Silverlight I'm a bit hesitant to latch onto MVC for fear it will be dropped about the time I've figured it out.

Any thoughts are appreciated.

[rockfordlhotka]

I think at this point very few people would recommend using Web Forms unless you are maintaining an already-existing Web Forms project. It has been quite a few years now that ASP.NET MVC is the preferred technology for building new sites/pages.

[GreggThelen]

I know I seem overly cautious but with the time and money that gets sunk into these projects I don't care to have another Silverlight fiasco; granted, nearly everything I learned in Silverlight (XAML, MVVM, etc.) transfers rather easily to other approaches so it wasn't a total loss. (I waited until Silverlight 4 to invest in Silverlight, burned two years later.)

I absolutely HATE web development, however I'm half way through Pro ASP.NET MVC 5 by Adam Freeman and I'm so much more comfortable with this architecture than I was with Web Forms. The amazing amount of control and separation of concerns is actually giving me a bit of a buzz for web development.

I see you have an 'older' CSLA and MVC book out - is that still a good source for integrating MVC 5 and CSLA business objects or do you have an update forthcoming?

Thanks again for your time and answers.

[rockfordlhotka]

The biggest risk in web development isn't on the server, it is on the client with the myriad JavaScript libraries that come and go like fireflies... You can't really build anything without taking 6-12 dependencies, and the odds of all of them lasting even a year or two is quite low :cry:

I do hope to update the Using CSLA 4 book series this year. The support for MVC built into CSLA hasn't changed substantially since the existing book was written though, so it still has some value. The MVC framework itself has changed of course, but their underlying model binding (data binding) concepts have remained pretty consistent.

[rockfordlhotka]

All that said, I personally think that Microsoft acquiring Xamarin may cause a resurgence of interest in true smart client development with C#.

Given that you can now use .NET to develop native client apps for Windows, OS X, Android, iOS, xbox, Hololens, IoT devices, Apple Watch, Android Wear, and many other types of device/platform it should (imo) give one pause as to whether it is best to build an x-plat app using JavaScript when C# is available everywhere.

Then again, I'm biased because I prefer C# and .NET and XAML and CSLA - all of which also run on all those platforms :grinning:

[GreggThelen]

Now that I'm more than half way through the MVC book I have to agree with you that it would definitely be the preferred technology. All I can say is WOW for the amount of control it gives over a standard forms based website. (Nothing wrong with web forms, I just like MVC quite a bit more)

That said, I agree with you that XAML is a beautiful thing and I'd far prefer it to the HTML/CSS/JavaScript infection.

In your opinion is Xamarin far enough along to be used for a business application today - without significant changes orphaning projects in the future?

The reason I jumped into MVC at version 5 is because the first several versions of a new paradigm usually have significant flux and I like to wait until things have settled a bit.

[rockfordlhotka]

I've always said that UI technologies come and go like clockwork, so it is our responsibility to keep as much code out of the UI as possible.

When talking about Xamarin I think this is very true. Using CSLA you can build your business logic separate from your UI code - just like on Windows Forms, WPF, Silverlight, etc.

The Xamarin UI technologies today provide a couple options:

• Create different UIs for Android and iOS using each platform's unique markup and UI philosophy
• Create a common UI using Xamarin.Forms

Creating unique UIs per platform can provide better performance, but more importantly allows you to design unique experiences that best fit into each platform's ecosystem. This can be important for consumer-facing apps where the app is as much about branding as functionality.

Creating a common UI with Xamarin.Forms is a nice alternative, but you'll end up with a UI that is fast and functional and common across both platforms - so it won't necessarily feel entirely native to either - but probably won't be obviously "wrong" either.

However, what I suspect (and hope) will happen with Xamarin.Forms is that it'll be replaced by something more like UWP XAML over the next couple years. UWP XAML is superior in many ways, and obviously it is to Microsoft's advantage if the XAML dialects for iOS and Windows are the same, because it makes it easier to get those high quality iOS apps onto Win10.

A CSLA business layer works behind per-platform UIs, Xamarin.Forms, and UWP. So again, what's at risk here is the UI itself, not the business logic, service calls, data persistence, etc.

fwiw, you run the same risk if you build a "modern" web app, because the churn in the JavaScript UI frameworks is very high - Angular, Aurelia, Knockout, Angular 2, React, Ember, etc. Wow!

[MarkOverstreet]

I would also add that for standard business apps if you decide to go web, we find it faster to develop the UI in Webforms and DevExpress. Their controls are responsive and can produce a web app that will work across mobile and desktop. And using a forms designer is easier in a lot of cases than just a text editor with intellisense.

No, I don't work for DevExpress but I do like their controls:)