We are developing an application that is going to have a Desktop WPF app and a web-face on ASP MVC. My main question is, what is the way to go to make the work as less repetitive as possible.
My ideal is developing the WPF app in someway using the MVC pattern, so that we could just copy/paste the controllers from the WPF app to ASP and work only on the View part. Is that possible?
I have researched and found that for that kind of tasks I could also stick on to using XBAP, but, as far as we have researched, many people are having problems with launching them. Silverlight is also not a way to go :(
Any ideas?
Thanks for your time!
No, you can't "copy/paste" stuff from a Windows application to a Web Application. And no. "copy/paste" is not an optimal way of reuse.
You're going about this in a completely wrong way.
The main idea behind Reusability is to keep application components and layers decoupled from each other so that they can be ported to different applications or even different platforms.
There's no way you are going to share Presentation code between a Web and a Windows application (regardless of the underlying UI frameworks on each side) simply because the HTML-based Web UI is stateless in nature and a Windows application is usually developed in a stateful way.
What you need to do is to use MVVM in the WPF side (as opposed to MVC) in order to keep the application logic and most importantly the Business Logic completely decoupled from the UI.
This way there will be a much greater opportunity for reuse in any other platform. All your shared Business Logic and application logic will live in UI-agnostic layers which don't really "care" about the Front-End.
Not possible. WPF and ASP.NET MVC have totally different Views.
Only thing you could re-use is your back-end API. Instead of injecting your API classes into your ViewModels like you would with WPF, you would be injecting those same API classes into your MVC controllers.
I would advice to forget the idea of reusing large pieces of client code.
What I would recommend is to build a 3-tier architecture, so you could reuse all the service layers (business services and DAL) in both ASP.Net MVC and WPF applications. You'll still have to code a lot of specific code in each application.
If your main goal is to deploy a WPF application through the Internet, then XBAP is the way to go. Or Silverlight, as it's a mature technology that'll be supported for years.
Related
I am currently developing an ERP solution for a company. The requirements are as below :
They need one winforms based application which will take care of modules like HR, BSC, Inventory etc.
A web based solution that needs all employees to get access to their personal data, apply for leave etc. This needs to be an internet based solution which can be accessed from anywhere.
In future they also want a document management system which will be web based.
Right now we are already through with some modules in winforms application as that was the urgent requirement. For winforms we have taken a horizontal approach for layered architecture. i.e. each module is one project with its own datalayer and businesslayer within project. Now I need to start working on the web solution. I am just wondering which approach will be best approach to share the datalayer and model layer between the winforms app and web app. Also the web app needs to have proper security in place as it will be sensitive data. I have thought about 2 approaches which may not cover all possibilities available.
The approaches I can think of are as below :
a. make a web service which will take care of datalayer and models. host it on the server and access it through winforms app and web app. For this I will need to change the coding that I have already done. But it is acceptable as it will require minimum efforts as its a layer architecture. here the only doubt I have is, for winforms app it will unnecessarily go through the web service layer and make it slower.
b. Convert the datalayer and models into dlls. Access these dlls in winforms and web app.
Also regarding the web app which will be the better approach :
a. Should I go for MVC3 based web app.
b. OR asp.net and WCF?
The situation is that I am working on this project along with a colleague and we are the team of just 2. So we are the ones taking decisions about everything.
I have fairly good experience in winforms but comparatively less experience in web based technologies. I will really appreciate your opinions on this.
If you want your model types to correspond closely to your database schema, you could create them using the Entity Framework designer and the Self-Tracking Entities template. This will allow them to be easily serialized with changes via WCF and persisted to and from the database. You then have the option of either creating a custom WCF service to deal with the entities or could exposing your Entity Framework context directly as a service using WCF Data Services (OData).
As far as the presentation layer goes, the two choices you listed are not mutually exclusive. You can have MVC with WCF, MVC without WCF, WebForms with WCF, WebForms without WCF... Since you are going to need to create the service anyway, and MVC seems like the way to go these days, I would probably recommend an MVC application that uses your WCF service to access the data.
I'm in a situation where for the past year I've been developing heavily in Silverlight using the MVVM pattern. I've sold my project manager numerous times on the greatness of MVVM through its separation of duties, and have had some great successes where I've re-written views in a day, rather than re-writing the app in a week.
Recently we've had a directive to 'go mobile' that is compatible with as many mobile browsers as possible (eg. Not Silverlight). My project manager is under the assumption, based on my earlier work that I can simply write a new 'view' for mobile apps.
Question:
Is there a way to be able to apply my existing MVVM code to a mobile front-end that doesn't consist of Silverlight?
I don't think so. MVVM relies on constant interaction between the view and the viewmodel through notifications, commands, etc.
Since your code is in .NET, there's no chance to run it on the client side in a web application.
You could however use some MVVM javascript framework like KnockoutJS in combination with some MVC framework (ASP.NET MVC 2 would be the easiest transition). This is the most similar approach I can think of, but you need to migrate your current applications.
I'm starting to jump in to WP7 development and I have a few questions. My current background/experience is with ASP.NET. I'm new to Silverlight as a whole, so I have some questions regarding the architectural design of the application. I don't have experience with MVC, and it appears that Silverlight is based off of it. Is that true? To my original question:
Once the new developer tools come out, the app will have a SQL CE back end that, as a future release, will sync with SQL Azure. I'd also like to provide a web based application that performs the same functions, and interacts with the Azure database. I'm wondering how I should structure the app to minimize any code duplication.
I was thinking of using a generic n-tier architecture. UI > Business Layer > DAL (LinqToSql) > Sql. These classes could get re-used on the web too.
Silverlight is not really based on MVC. In fact, you can implement any architectural pattern as long as you fully understand its functionality. Most people prefer MVVM, which is similar to MVC, the only main difference is that the controller is replaced by the ViewModel that plays the role of an intermediary data link between the model and the view.
With the release of Mango, you will indeed have access to SQLCE. In your case, since you are planning on using specific interoperability layers, I would recommend building both applications in Silverlight with an intermediary web service that will communicate with the data storage (in your case it will be Azure). You win in two points:
You are using Silverlight, which means that you can use a similar codebase (with platform adjustments, of course) to deliver the same functionality.
The web service is app-independent. Therefore if you ever decide to build, let's say, an iOS application, you will be able to use the same communication layer without major changes.
I'm considering using Silverlight for a business type application which will contain probably a dozen or so screens. The screens will contain data entry forms with edit fields, grids, lookups, calendars, etc. Typical business application type screens. I want this to run in the browser but don't want to mess with HTML, JavaScript, CSS etc. Is Silverlight 3 appropriate for this type of application? Can someone build professional level business type apps with Silverlight 3?
#Randy Minder,
Glad to hear that you want to use silverlight 3 for line of business application.
I used to develop line of business applications in ASP.NET combined with javascript/AJAX. I am currently developing my first silverlight 3 line of business application and found silverlight is better in few departments. The following are the Pro/Cons observed by me PERSONALLY.
Pros
Layout/Styling(CSS)
XAML + silverlight 3 styling is very flexible and less cluttered when compared to CSS. I am not a designer and I hate having to deal with CSS. But in the case of silverlight, I really enjoyed creating the mockup,layout & styling. The end result is awesome. This is the first application that I developed has decent & consistent look & feel. I hope you will also find silverlight xaml to be easier to deal with.
Rich Interaction & Language support
I used to use Ajax, javascript for creating rich interaction experiences like populating some data dynamically when user interacts with UI. Writing some complex UI logic in Javascript is daunting. Though there are some nice javascript libraries like Jquery, I think writing UI complex logic in C#/VB.NET/F# is much easier than to write it in javascript. Dealing with rich interactive controls in silverlight is much easier than with javascript/ ajax controls. Writing server communication code with WCF or WCF RIA service is far easier than with ajax calls.
Browser compatibility
Each browser is different from another in one or the other way, like some browser supports something and others dont. Having to deal with browser differences in javascript is also a pain. Silverlight being a plugin doesn't have to deal with browser differences. No problems dealing with layout engine differences too.
Animations/multimedia
Ofcourse with line of business applications we will not use toooo much of animations/multimedia. However we can use small animations like menu popup, sliding controls, fading transitions for when data changes etc. These are very easy to implement in silverlight than with asp.net/javascript
Validation
Validation support in silverlight is awesome you can write more validation logic in less time.
Popup messages
Popup messages are very clumsy to deal in ASP.NET and sometimes I need to store some information in hidden fields to feed text for popup messages. Hidden fields are used as javascript & ASP.NET interaction components which are difficult to maintain and end up with more code.
Good separation of presentation & model
Though you can separate these layers in ASP.NET also, silverlight enforces this by design which is good. In my team there are few developers who dont want to put effort on separation of the layers. Unfortunately they are the seniors in age and decision makers. I always hate to deal with their spaghetti code. Not to say that I am a better developer than them, I always put some effort to separate the concerns and try to learn how to manage my code. ASP.NET webforms doesnt enforce separation of presentation & model by design. Where as silverlight enforces this by design and my life became easier.
Cons
Clipboard
Users are very much used to copy the content available on ASP.NET/HTML page. Most of the silverlight 3 controls doesnt support clipboard out of the box. The only control I know that supports out of the box is textbox.
Database Communication
Database communication in ASP.NET is easier & direct communication is possible. However silverlight being client side technology it doesnt have direct access to database and a necessity of creating an additional tier is mandatory. Though WCF RIA services make the development of this additional tier easier, still WCF RIA services is in beta as of now. Though I am mentioning it as disadvantage, I did not really feel it is as REAL disadvantage because creating a WCF service is not that difficult.
Client side resource usage
Though cost of hardware reduced alot,client side hardware resources are not unlimited when compared to server side. At my work place, though PC provided have decent configuration, most of the users open lot of applications simultaneously which is required to accomplish their day to day tasks. Silverlight uses client side CPU/memory. Some of my users are complaining that the application I developed is using more CPU/memory than the asp.net equivalent. So if your users have slower PCs, consider ASP.NET or design your silverlight application more carefully.
One may say installing silverlight plugin as disadvantage, I did not face the problem because my application is a intranet application and all users installed silverlight with a single email request.
These are MY experiences with silverlight 3. The only major issue I faced was clipboard support in silverlight, I hope MSFT will address this soon.
All in all, silverlight ROCKS!!! Silverlight 3 is ready for enterprise and if you can wait for few more months Silverlight 4 will be released which has even better support for line of business applications. I dont want to develop ASP.NET applications anymore, that doesnt mean that I will quit using ASP.NET, I will use it only when necessary. I fell in love with silverlight and for a good reason. Designing part of the website is the one I used to hate most but with silverlight designing became one of my favorites.
I hope that silverlight 3 will help you in your decision making.
Absolutely. Take a look at this post about the Vancouver Olympics:
http://csharperimage.jeremylikness.com/2010/02/vancouver-olympics-howd-we-do-that.html
That's just one example of a business application in the "real world" being used to drive a massively complex operation. I posted that just to draw attention to the "business" side of Silverlight, but be sure to click the link to the original post to see the other partners and contributions to the project.
I've been building enterprise/business applications with Silverlight for over a year now. So the answer is an emphatic "Yes, you can" and "Yes, it's been done" and "Yes, it's been done on a large scale with large companies, and very successfully."
I agree #Jeremy. Make sure to use RIA Services with Silverlight , You will get a very manageable/maintainable application. Even one more benefit is that you can make the SL app Out of browser too.
We are developing/mantaining an enterprise application which for historical reasons and development speedup it was targered for WinForms.
Now we are thinking that sooner or later (more sooner than later) that application will need to be Web based.
Thinking on the "to-Web" movement. Which are the most important things we have to consider? Something like, thing on MVP parading (or others), determine now the kind of platform/framework you are going to use, ...
Any experience on migration from winforms to web? Any suggestion to take care?
Aclaration: In our scenario the application would be nice NOW to be Web based but we are realistics. I agree that not all the applications have to be Web based (this is the main reason we developed with WinForms!). But sometimes the requirements changes and, in our scenario, we want to offer that application as SaaS.
The main thing is to completely separate the user interface from everything else. Once you've done that, you won't be rewriting the application in order to port it - you'll just be creating a web UI on top.
NESBAWA (Not Everything Should Be A Web App).
I worked for a company that went through a similar situation with their monolithic WinForms application. From that experience, there are two things to consider:
1] Decouple all data access logic (DAL) from the existing WinForms UI. You can start this process before any web development begins.
We did this refactoring in a series of 6 weekly sprints. Some parts of the app were easy to change - others were made of completely hellish spaghetti code that interwove DAL, inline SQL and UI code all in the code behind of the WinForm.
Once you have this separation in place, supporting two different UIs is easier.
2] Ignore ASP.Net MVC and target WebForms. WebForms was designed to make writing a web application close to the experience of writing traditional WinForms UI code (event driven, component based).
You need to understand the page lifecycle, and there are a few conceptual gotchas around dynamically generated controls that tend to trip up a lot of newcomers - but otherwise it's the most painless way to get a team of WinForms developers doing web stuff. MVC maybe very popular in web circles right now, and it provides a better separation of concerns (though you can achieve similar results with WebForms with a bit if diligence and strong design leadership) - but it requires a higher degree of knowledge. With MVC you're working closer to the metal of the HTTP request/response cycle. WebForms abstracts away a whole lot of that for you.
Best of luck in your endeavour!
John is right.
However, have you heard of the "Empty Client" approach? This is a fairly new approach to developing .NET WinForms applications that can also run as web applications on plain browsers. That approach would allow you to develop your WInForms application and put it on the web if and when you desire with no additional development or adjustments.
One framework that does it is Visual WebGui