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)
Related
I was given a project in WebForms to make robust and I had so far added several improvements to it. Don't get me wrong, I like WebForms for its simplicity but much of it is I feel like 'grandfather' type of coding.
Here's what I did, just to give you some ideas:
1.) Added VueJS to the frontend
2.) Added Webpack and a bit of ReactJS to on some pages
3.) Used .NET core on running a custom protocol app that triggers from inside the WebForms project
4.) I've added an emailing function (Inbox, Sent Items, Drafts, Trash, Junk, etc.) (from WebForms and jQuery, another one was WebForms + VueJS) to it as well.
It has gotten pretty big. I was just wondering if it will be scalable? Our management is thinking of putting it on the cloud soon but I believe it wouldn't work because of the architecture of our project - we will have to slowly transition it to modern web standards (apply MVC, use WebAPIs rather than WebMethods (static) on CodeBehind files).
I really am lost. What's the best route in improving a WebForms project to modern standards? Something scalable and cloudable (if that even is a word).
Thanks.
(Let me reach for my flame-retardant underwear.)
The big difference between WebForms and more contemporary web design frameworks is that WebForms attempts to layer an event-driven forms management paradigm on a platform that is not built for events. Web pages are not desktops.
In my experience, the efforts to maintain the illusion of web events in a complex application far outweigh the investment in taking the original functional requirements to MVC, or NodeJS, or React, or some framework that is designed for the calls and responses of the stateless servers of the Web.
I vote do-over. You will have to do your own cost/benefit analysis if you want to take that route. If you do go that way, this forum is a good place to post specific questions with code samples related to coding problems that you uncover on your journey.
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.
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'm trying to figure out various pieces that need to go into building for the mobile web with .NET / C#. I've so far been working mostly with native app development (iOS / Droid / B'Berry) and have very little experience with web development in general. But for the current project I'm working on, I believe a web-app is the way to go and would like to figure out what I pieces I need to get it working.
To give a brief overview of the application, our company uses SQL Server / .NET / VS for all of our web dev projects. The programmers here are familiar with this stack and I would like to keep it that way if possible. We're building a new product that needs a web + mobile view. The web view is currently being built as a separate project completely, but that can be changed if needed.
I'm just looking for some input on how to design something that handles screen resolutions, device types etc. and creates layouts appropriately in VS. Also, any best practices when trying to do this are much appreciated.
Thanks,
Teja.
handles screen resolutions, device types etc. and creates layouts appropriately
This is all presentation layer and shouldn't be a concern for any development framework. Sadly, it is. For instance, I'm currently working with a JSF team and so much of the presentation layer is produced via the JSF framework and it's a nightmare to maintain a sane presentation layer code base that way.
.net used to be that way too. Much of the early days of asp.net was full of invalid markup, bloated generated JS and the legendary postback cache tag.
Ideally, you'd have a presentation layer team that was independent of the particular framework. Mobile apps, more than anywhere, require the ability to maintain a lean, streamlined presentation layer and the best way to handle that is to let your team write their own HTML, CSS and JS as needed. I've worked with a C# team that was heavily using RESTful services that worked fairly well. We had built our own template framework and all HTML, CSS and JS was completely independent of the back end C#.
Fortunately, MS has gotten better and newer ways to implement via asp.net (such as the MVC model) can hopefully offer you better management of the presentation layer.
I need to build an application in C# that will have multiple UIs, 2 for web and one that will be the same application, but able to be used with no internet access. I am leaning towards MVC for web, then MVVM/WPF for the windows application (Silverlight is not an option). I should be able to inject a different repository implementation for the two paradigms, thus solving the disconnected-from-the-internet issue.
What I am wondering is how best to re-use as much presentation logic as possible. Ideally, I would like to be able to use the same controller/presenter-type entities to run both UIs. I'm looking for an example of a good solution to this problem. I don't see a clear path to re-using MVC's Controllers (they seem too tighly bound to the MVC framework to work), but at the same time I'm not excited about the overhead involved in implementing a custom MVVM or MVP pattern for the web (which I fear is the answer).
Alternatively, am I crazy to even try to re-use those components? Is it not worth the hassle? We can easily share the services underpinning the UIs, but it seems a shame to write such similar UI code twice.
The right thing to do is to share only the Business Layer and Database Access Layer. At least you will have consistency between all the clients.
Then build the clients taking advantage of the benefits of each platform (richness of the desktop app and simplicity in the web app)
Of course it all depends on the budget.
You have the option of using WPF for everything for max re-use. WPF can be deployed as partial trust XBAPs.
There are downsides though
* Download size can be a problem
* Clients need the correct framework version and can only run in Internet Explorer (Firefox through plugin (not working on Windows 7))
I've tried it on a solution with a small XBAP client and a larger Standalone Application - and it is really minor details that cannot be reused (Window in app, Page in XBAP and so on). Makes for nice consistent layout too.
This is slightly hackish (and not really recommended, unless you really understand what you are doing :)), but you could try creating a desktop app, which embeds a browser. This enables you to reuse the GUI. You will also need to package a web-server, which might be a problem though if you are using C#/MVC/.NET.