I'm about to start up a large project where the same database will be queried by three different applications/sources.
First application will be a WPF app for use on PC (duh)
Second will be this handheld device som PSION: http://www.psion.com/us/products/handheld/ep10_specifications.htm
And last there wil be a website (MVC3 I think)
For the WPF I think I'll go with with MVVM pattern (or will MVP make more sense maybe?), but when it comes to the handheld device, I'm clueless as to which pattern/arcitecture to choose. Is it even possible to have some sort of arcitecture on such a device?
Anyone got any experience with this? :-)
Any help/hint is appreciated!
/ Bo
If you are planning to use Windows Mobile 6.5 along with the .NET Compact Framework 3.5 SP1 (in Visual Studio 2008), the most common approach is to use Windows Forms (Compact). If you are planning to use C++, you can ignore the rest of this answer as I'm not sure what the best practices are for C++.
Windows Forms for .NET CF is similar to the full framework Windows Forms, but much more limited in functionality and out-of-the-box tools. There is really no WPF/Silverlight/MVVM options readily available for the legacy Windows Mobile platform, but you can try to roll your own MVVM type framework if you're brave, but I probably wouldn't suggest that as MVVM works better with WPF or Silverlight, and may not map to Windows Forms as well as other options.
There are several MVC or MVP examples or basic frameworks out there for .NET CF Windows Forms, but I haven't seen one that's really full-featured. You could try the "Smart Client Software Factory" for Windows Mobile from the Patterns & Practices team at Microsoft, but I'm not sure I would go that route, as it can be overly complicated. Search google for "Windows Mobile MVC or MVP". A lot of times the MVC/MVP examples only show a single screen, which does not give you any idea how the author intends to handle application screen transitions, global events, etc.
I would probably suggest the MVP pattern over MVC as MVP works well with Windows Forms. MVC can be a little awkward with Forms, unless you do it very carefully. This is the best example I've found of a multi-screen app on the Compact Framework using MVP in .NET CF:
https://github.com/derickbailey/appcontroller.cf
This is a great example, as it uses modern best practices like IoC and UI event aggregation. The other bonus of this example is that it sets the stage for good unit testing and good practices for UI development.
Related
Please suggest me some good MVVM and IOC application frameworks that can maximize code sharing between Windows 7/8 and Windows Phone 8 (and possibly for a Modern UI app in future)
The desktop app will be WPF based and the Phone app will be XAML + C# based.
The overall application will composed of pluggable components that can be dynamically enumerated from assemblies.
We also want to go with the purist version of MVVM where Model, View and ViewModel can reside in their own independent projects. We also need the ability to compose a view from multiple sub views which can reside in their own assemblies.
MvvmCross - Stuart's blog, videos, jabbr room
MvvmCross is an Mvvm framework tailored for development targeting Xamarin.iOS, Xamarin.Android, WindowsPhone, Windows Store, WPF, and Mac. Personally, it's still a great framework even if you're only targeting WPF, WP, and Windows Store.
It has a plugin model for cross platform components, implements it's own IoC container, and has a messenger, among other cool things. MvvmCross implements bindings for the different platforms as well and as a result can do some cool things with bindings, see Rio.
Caliburn Micro - docs
Caliburn Micro targets the XAML technologies, WPF, SL, WP, WStore. It's has a lot of conventions for doing things like auto binding a button to a method by matching the name of the buttonx:Name="Send" to the Send method on the view model. All of the conventions are configurable. CM also implements it's own IoC container and has a messenger.
QuickCross - A lightweight, code only, Mvvm framework. Interesting and worth looking at.
MvvmLight - also excellent and provides the essential Mvvm things.
All are excellent open source projects with healthy communities. I'd suggest writing a small to medium sized application with a couple. They all have great docs but the source code can provide further insight.
I don't know about what your application looks like, but first thing I would do is to develop the WPF application using a 3-tier architecture so the "back-office" part (i.e. server-side) of the application exposes WCF services that are developed once, and can be consumed by all your clients (Windows Phone, WPF, Modern UI app...).
Then for the client side, I would suggest using the PCL release of MVVM light Toolkit. I haven't tested the PCL version yet, but I always recommend this library for MVVM developments.
That being said, if the "pluggable" requirement you have is strong and you don't want to build it from scratch, you might want to have a look at Prism. I didn't have a chance to test it yet, but it's worth trying as it's supported in WPF/Silverlight/WP7 scenarios.
Has anyone heard of a way to port or convert a C# desktop application to a suitable web technology. The important factors here would be high framerate, used for displaying flashing objects onto the display.
Or, alternately what is the best web language to use for a good response time (JS, Java Applet, etc). If anyone has done anything with similar requirements, what have you tried?
EDIT: It's a C# .NET 2.0 Windows standalone desktop application. I really don't know anything more, I was just wondering if any technology exists for any kind of C# application to any kind of web technology. This is for a job I'm applying to and I was just asking this for insight.
This is a very subjective question, but I have been doing some web development that specializes in creating highly dynamic front end environments so I can give you my two cents.
You are a C# developer (which implies you have used .NET in the past). If you want to remain loyal to MS, you could try developing web application using their ASP.NET MVC frameworks. I would shy away from Silverlight as MS has no intention of actually enhance it from what I have heard (Build conference).
Personally, I have been using AngularJS, HTML5, D3.js to create highly interactive, data visualization applications that resemble in terms of interactiveness a desktop app.
EDIT:
On the last Build conference, it was easy to tell that MS was trying to push for web technologies over desktop technologies. They are pushing stuff like HTML5 and Typescript (which integrates nicely with VS). They had no mention of any desktop technology which infuriated quite few people. So, if you want to embrace the future: go for HTML5 and JavaScript (Typescript)
EDIT 2:
Links:
http://angularjs.org/ (A very easy to use MVC front end framework, it goes nicely with the ideas behind MVVM)
http://www.typescriptlang.org/ (Microsoft's favorite flavor of JS)
http://d3js.org/ (A very cool library for data visualization, if you are interested)
Well, you have Silverlight, which can use C# that can do serious graphics, but it probably doesn't have much of a future. Microsoft has it on the axe list.
You could always use HTML 5 Canvas, which has very good support for complex graphics with high frame rates. You are going to have to rewrite your code though. I have never heard of anything which can convert a WinForms application to the web with any degree of reliability.
MVVMCross ironically doesn't seem to include Asp.NET as a supported platform. Would it be hard to use MVVMCross under an Asp.NET environment implementing views? Has anyone done this? What would need to be done.
The underlying exercise would be to retain as much code independence across Windows, iOS, Android, Mac and a Web interface - Ideally ASP.NET using mono on Unix.
MonoCross, one of the 'inspirations' for MvvmCross, did actually support web-based views alongside server-based viewControllers.
However, in my opinion it had limited use, required too much server-side memory, placed limitations on mobile app design and really wasn't a good programming model for many webapps.
If you really wanted to support MvvmCross in a webapp then you could look at:
where you will put the division of logic between web-browser-client and server
how the server(s) will maintain session state
how the HTML/Javascript clients will communicate in-page with the server
how remote-client specific errors will be overcome
For a specific category of apps, there is perhaps some sense in doing this.
But for more general web apps, I think there are far better solutions out there - using knockout, angular, Nancy, Fubu, ASP.Net, etc
MvvmCross remains focussed on rich client apps where local in-memory state is commonly much larger than in web-apps.
Alternatively...
at least two people have started on Silverlight MvvmCross ports (but I've not seen the output of either)
see Using MvvmCross in a web project
https://github.com/Larochem/Cirrious.Mvvmcross.Silverlight
one open source dev is promising a future all-platform-including-html mvvm engine called Carnival (I've not seen this in the flesh yet but he does have it working on an internal project)
I'm pretty excitet about all the new stuff coming up in Windows 8, but at the same time a bit worried about how and if I can continue use the code and custom components I have already built up using .NET and C# during my time as a Windows dev. I've got some general mixed questions about this. Hope you don't mind I'm putting them together in one post:
Will Windows 8 Store be for both metro-style apps and regular WPF-desktop apps? Including pushing updates and making apps available for company employees?
Will the new App Contract-thingy also be available for WPF-apps? And is AppContract based on WCF-services with perhaps UDP-discovery on the network? Can I make my own contracts between my own apps using the App Contract framework?
I'm not particularly worried about if WPF will be ditched or not. I can live without it. The thing that worries me is if I still can write presentation and business-layer code in C# and use it as a backend for my apps, no matter what UI-framework I'll be using, HTML, Silverlight, WPF or what have you. If I'm still able to write logic in C# and present it using X UI-framework, I'm a happy developer. I've heard I can access the .NET-framework from JavaScript. But what about custom assemblies?
It has been announced that non-Metro apps can appear in the store but the store will just link to the publisher's website - not actually manage the sale/install/DRM/etc stuff.
What's been announced so far is that the contracts are only for Metro apps but I'd be shocked if this doesn't change. It would be crazy for Microsoft not to allow desktop apps to, for example, add commands to the Settings charm, support PlayTo or printing through the Devices charm, or act as Share sources. We'll have to wait and see where they draw the line on what desktop apps can/can't do.
Sharing code between Metro and non-Metro apps is going to be very difficult. A lot of the core concepts and conventions are the same but even basic stuff like file I/O rely on a totally new API. There aren't a ton of interesting things you can do with in code that will work on both sides of the fence. Best bet would be to define interfaces for your business layer stuff and then use dependecy injection to dynamically select desktop vs. winrt implementations at runtime
Store: there is no final information but as far as I understood it, it's for metro style applications only
The app contracts are a metro thing. I know a code snippet that documents usage from desktop apps (eg http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), but I do not know if it will have support from Microsoft
WinRT compiles libraries to WinRT components. You might be able to reuse code and compile them to a component as long as you're not using a namespace that isn't available for WinRT
This question is heavy on guessing as there is no official beta available. And even then we can't be absolutely sure...
I've been playing around with C# console applications for about a year and I want to move on to creating GUI applications. I have never done any GUI development besides basic Java applications, but I want to continue using C#. Should I start learning Windows Forms or jump straight to WPF? Is there a huge difference? Does WPF build on top of Windows Forms or are they totally different?
If you're just starting out, jump straight into WPF.
It will allow you to get starting making rich interfaces using mark-up to define your interface without teaching you the possible bad habits (for WPF) that you'd learn from Windows Forms.
These two are totally different technologies. They do offer some interoperability layers to both directions, but other than that have nothing in common. Windows Forms is more or less a lightweight wrapper on top of Win32/MFC, which means its extensibility in .NET is not that good in all cases. WPF is a new UI framework implemented from scratch. WPF is also much more flexible when it comes to customizing the existing types.
However, at least from my experience, Windows Forms seems to be the more commonly-used desktop UI framework in the industry. Windows Forms can't be used with web development though while WPF offers Silverlight and XBAP applications.
If you have done any UI development before, I'd dare say Windows Forms is easier to learn as it follows more traditional programming paradigms. The programming model of WPF is quite different to this. While WPF can be used in the same way as Windows Forms, most of its benefits are not achieved until you embrace the data binding and encapsulation WPF provides.
Despite stating some points in favor of Windows Forms choosing WPF over Windows Forms would be a no-brainer for me if all you want to do is learn a UI framework. It's superior to Windows Forms in all aspects. I just wish the software industry in general would adapt it on a larger scale! (Though not like anyone writes desktop applications any more since we got the web.)
Both technologies have their pro's and con's.
WPF is better for cross platform development and creating 'flashy' GUI's. However it requires a newer .net framework than WinForms and requires a dx9 compatible GPU or higher (which most people will have).
But it is a little bit more involved to create the interface / wire up all the events etc.
WinForms is still a powerful technology which can often be developed at a faster pace than WPF however, in the end, both technologies can be used to achieve the same thing. However WPF is the 'newer' standard.
WinForms is commonly used to develop business applications whereas WPF is often used to create more end-user based bits of software, apps etc.
WPF provides very rich facilities to build extremely complex user interfaces. It simplifies integration of a hardware-accelerated graphics in your interface. However, the Visual Studio WPF designer is really bad (I almost never use it). I also think that WPF is much more complex, and it is more difficult to start with. But this is subjective of course.