I am in the first step of the design of an application that would support two completely different UI, and I would like to do it with the minimum duplication of code.
The first UI would be a windows application (probably with WPF), that will be the most used, the second would be a web application accessed mainly through mobile devices.
Knowing that the WPF application have to work completely disconnected from the network
and that once in a while, it must be possible to synchronize the work done offline in a central server
Here is what I was thinking to do:
WPF version:
MVC style WPF application, SQL server compact/express on each workstation and entity framework for data access, organize so that the WPF model, the entity model, and the controllers are in a separate assembly.
In addition, we will need a SQL Server database to synchronize the work of everybody.
Web version:
This is where things get blurry in my mind:
If I do an asp.net MVC application, modify it so that it is mobile friendlier, do you think it is possible to reuse the model, entity model, controllers, validation, etc. ?
I am still in the early stage of the design, and I am not familiar with asp.net MVC, so if you have other solutions, that would help a lot.
Also I will create and post here a POC when I will have a good design, so that it can be reused.
I would suggest the following:
Build a Service Layer (http://martinfowler.com/eaaCatalog/serviceLayer.html) using TDD (http://en.wikipedia.org/wiki/Test-driven_development) to encapsulate the functionality of your application.
Build a remote facade (http://martinfowler.com/eaaCatalog/remoteFacade.html) on the service layer to service remote clients (WPF, Andriod, iPnone, WP7 etc etc)
Read up on MVVM and Prism4 (http://compositewpf.codeplex.com/) before starting the WPF app.
Build the ASP.NET to access the service layer directly/in process.
Hope this helps, good luck!
If you're developing in WPF then forget ASP for your web based code. Structure it using MVVM pattern.
It's not a vast step change to have the same WPF application switched to be browser based (that's part of the point for WPF), certainly far quicker than writing a second app. Have a look here for information about WPF (applications and browser).
What form of data transfer is required - have you considered MSMQ for passing data to the server. This then wouldn't care if there was a connection or not and once there is data would be transferred without any work on your part.
Related
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.
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.
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.
First off I have to say programming is not my strong point but I'm working on a project that does not need to be elegant, it just needs to work.
I have three parts to this, a Chrome Extension, a WPF application and a WCF service. I need to POST/GET data between the Chrome Extension and the WPF application. For simplicity sake, I have a variable that needs to be updated real-time in my WPF application from the Chrome Extension that outputs JSON objects.
1) The WPF application and the WCF are now two different projects in the same solution. I am not quite sure how to merge this so I only need to startup one project. Or perhaps, should they even be merged? The variable to be updated is in the WPF application.
2) I'm not quite sure how to get the Chrome Extension and WCF to have a continuous stream of data between them.
3) Any advice would be great, feel free to ask any questions.
Cheers,
Josh
A few thoughts:
The WPF and WCF applications should not be merged into the same project but depending on your use case the WCF service could be embedded into the WPF application if the service only needs to exist whilst the desktop application is open.
On a side note you can start both projects at the same time during development with multiple startup projects in your solution configuration.
Think about your architecture. If the variable to be updated is in the WPF application then the WCF layer is mediating between the two. Bear this is mind.
There are many ways to achieve a 'continuous' stream of data between a JavaScript application running in the browser and a Web Service. WCF does support persistent duplex communication although I doubt it would be easy to integrate with a JavaScript application. Another option would be to look at the various web sockets implementations. However, before you make this decision you need to clarify your requirements:
Is the flow of data one-way or two-way?
Does the WCF application need to call the JavaScript application?
What do you really mean by 'continuous stream of data'? Would regular polling be sufficient?
From the information you have provided and for simplicity's sake I would suggest having JavaScript call the WCF service when it has new data to send and then the WPF application polling the WCF service for any updates. I cannot tell whether or not this WCF service ought to be embedded in the WPF application though.
I am on a quest to find the best method to implement this data structure in my WPF c# .NET 4.0 web application.
App Details: This application will have many users at one time. I'm working with a database that has 2 tables linked together, both with <10k rows, but they will grow with time. One table will need to be checked for updates periodically.
Question:
I created a dataset to hold all information. My unit test shows it takes ~0.2 seconds to populate the dataset from the database. This is no time if the dataset will persist across the application. Can it persist across the application for many users?
The other method I can think of is using observable collections for the data and storing them in a singleton. Is there any method that I am missing here or something that will work better for me?
I think you're misunderstanding some really important concepts here. First of all, WPF is not ASP.Net, WPF applications do not "run at server". WPF applications run at the computer that executes them (I.E the client) regardless of being an XBAP that runs inside Internet Explorer.
Therefore, you cannot have such thing as a "singleton" shared between many instances of your WPF application because each instance will be run on a separate computer on its own process. There's no practical way to share memory between these instances.
Then, if you need a "Web Application", WPF might not be suitable for your project. WPF is not a web technology, it is a rich desktop application technology that does not depend on the crappy implementations of HTML or anything like that.
Now, if you need (or desire) the richness and awesomeness and ease of development WPF provides, you will have to implement a Client/Server application, possibly using WCF or any other communications technology to enable your rich Client to communicate with the Server.
The "Server" will be an application responsible for querying the data from the database, then possibly caching it in memory, and then sending it to the client. Usually a WCF Service application is enough for this, although depending on your requirements you may need to implement more layers on top of it.
Beside this, I don't think there is a good reason to send a WPF client 10k rows of information, so you will have to come up with some paging mechanism in order to send the data in "chunks" instead.
Please provide more details about what you need and I can give you more insight.
I have a working WinForms application, written in c#, which is divided in several layers (Data layer, Model, business logic, common layer, etc). I would like to allow users to use web browser also for data manipuolation. Do I need to make some kind of in-between layer, or I am safe with using business layer from Web forms? Also, what kind of MS technology should be used on the web layer, as I see that we can use both classic ASP.NET pages, Silverlight, or maybe something else? The application itself has several forms for entering data, and many, many different forms with charts and reports.
Thanks in advance.
It's hard to make a recommendation without knowing your existing app details. There's also no one right answer. Silverlight, ASP.net (MVC), Javascript/jquery/ajax are all good technologies that have their place and use. But, as you decide for yourself, here's some thoughts and things to consider.
A thick winform app is typically a fat client with local state. Your data model etc... may rely on state to be persisted across many requests in a fatter local process.
A thick winform app is typically used by the one user & process - unless you're coding concurrency, your app may not be thread safe.
A web process is shared by multiple users making requests - any shared state will need to consider concurrency and memory footprint.
You typically want the web process to hold less state and drive more of the client experience down to the client - thus the popularity in ajax, jquery etc... More javascript technologies.
Silverlight is closer to your winform process - it's hosted in the browser plug-in with the state and code being accessed by that one user. You will have to change the view layers to silverlight but you might be able to retain your model and data layers.
Running in a silverlight plug-in does have more restrictions (sandboxed) than a full winform app. http://msdn.microsoft.com/en-us/library/dd470128%28v=vs.95%29.aspx
Many folks like ASP.Net MVC - check it out.
Javascript approaches using ajax, jquery, etc... has gotten alot of momentum in recent years. Be aware that will be a bigger shift from your winform code which may be good or bad depending on how you look at it.
I just got a project to be build up from scratch. Its front end will ASP.Net and Backend is SQL 2008. The requirement is, the architecture of the app should be such so that we can have access to app from any computers(desktop, laptop, netbooks) as handheld devices as well like smartphones, PDA's, Tablets. Also it should be plugable in nature like FB and orkut. That is in future if the client needs to attach games or third party applications, then it should be plugged in without rewriting the entire thing again. Also client needs the entire web ajaxified either using the toolkits or JQuery.
I have prior experience of ASP.Net webforms applications with tiered arcitecture. So this time keeping his all needs, i am thinking of a web app with WCF Service. But i have no idea or experience about the pluggable architecture with SOA and MVC (all three). It seems if I implement all the stuffs, it will going to be a mamoth of codes. For pluggable arch I googled and found MEF on codeplex. So finally I came up with the following things :
ASP.Net MVC
MEF
JQuery
WCF
RESTful with AJAX
XML
Guys, i really need your help, I am unable to think how to place all these stuffs together. Or is there any other best alternative you can suggest for.
Also, there is one more requirement by the client is that he want the loose coupled code, that's reason i chosen MVC, the aspx page can only have the controls and required HTML, validation and other codes should be done in the Business Layer of the app.
it will be great help.
You should take a look at Orchard: it's an ASP.Net MVC CMS system that is very pluguable. You can add a lot of functionnalities through modules, and there are a lot of modules already implemented and accessible.
Even if you do not end up using Orchard itself, taking a good look at its architecture should be a very good starting point for your app, as Orchard responds to a lot of the same requirements you have, and as it is an open source project, you can get as much inspiration from it as you want.