asp.net vs asp.net mvc for a converting a WPF application

Question

We released a WPF client server application this year . It has a client (with a few dlls ) and server on the server machine (with multiple dlls with most of our logic). The server side uses Entity Framework and the service between them is TCP /IP Windows communication foundation (WCF).

The client uses MS Prism with Mef for MVVM. The UI has a number of Datagrids for storing , saving data.

For WPF we have : XAMl -> View Model -> Service Interface -> Server Side code -> DB

For ASP.NET , we expect to use the layers from Service Interface onwards as it is. So , basically we need : Website-> Logic for data handling on client Service Interface -> Server Side code -> DB

Unit testability is not a very major concern as our unit test coverage looks good on the server side (85 % covered).

I read up on ASP.NET MVC and found some tutorials that spoke about building whole applications on the MVC framework .

Our case we have more than half of the application built and only need the client side web UI with same data .

My question is : Should we go for ASP.NET Web forms or MVC ?
Web forms have native controls like GridView which can be used. MVC doesnt provide much native controls support . MVC covers the whole web app full stack. We only need the client UI website.

People around have recommended MVC since it is new and looks like the way forward but I am wondering if it would be overkill considering our requirements ( only need client). Would MVC force us to rework our whole layers even on the server side ? Will aSP.NET web forms not do this ? We want to be able to use WCF instead of doing any other http framework like webapi.

I know this question has been done to death with but these are some speicific requirements here. I also read up on porting WPF apps to Web but tat probably wont work out as we may have some fucntionalties different in the Web vs WPF.

Answer 1

You are making a small confusion. Since you have alredy a WCF(SOAP) backend service you will write only the UIClient, regardes of technology. You can do it even in Java.

Since you rewrite the desktop client, as a new web client you have to do it from scratch, and so should use ASP.MVC. You can find a lot of forums which can tell you why.

Web API is used, only if you want to create REST services in MVC. But you can build them also in WCF if you really need them.

The only good reason for ASP.NET, will the fact if you have developers which already know it, and you can save some money.

Answer 2

Having worked with both MVC and Web Forms I would highly recommend going with MVC. In my opinion Web Forms is an antiquated pain-in-the ass that doesn't lend itself well to scaling or unit testing(which I know you said is not a huge concern).

Yes, Webforms has native controls like gridviews but you aren't missing out on much. These are good for very simple things but as soon as you add some complexity to your tabular data you're going to be pulling your hair out. What I'm trying to say is you can accomplish the same thing these built-in controls provide but with greater flexibility using simple tables or just plain old divs(and some css, of course).

I should also note that both MVC and web forms work just fine w/ WCF. You don't have to use WebApi if you're using MVC.

Lastly, I don't think there's an easy way of only providing "the client" piece of what your trying to accomplish with Microsoft technologies. If I understand your question correctly, you have a desktop application and now you want to provide a web-based equivalent UI. You're going to have to create a site using webforms or MVC to achieve that. However, you will be able to reuse your web services so you won't have to rewrite too much business logic.