Does anyone have an architecture for a REST application optimized for mobile. The architecture I would like to see manages REST requests and responses in conjunction with a database. Ideally I would like to see an architecture that has the ability to scale and is flexible to change.
You should take a look at MVVM architectural pattern. There are tons of MVVM tutorials but you can start with Silverlight client for REST using MVVM post. Also see this question Good architecture for consuming a REST web service in an MVVM app for Windows Phone 7?
In my experience RESTlets and Hibernate are good solutions for implementing a REST to Database solution using ORM.
Related
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.
We are starting out with the development of a Silverlight app that will make use of Windows Workflow Foundation (WF4). Our workflows are long-running. We plan to use the tracking and persistence functionality of WF. We will probably need to also store data related to each workflow instance in another DB (I suspect running reporting against the workflow persistence store would be tricky). Our workflows may change with time so we would probably also need some strategy to implement versioning on them.
So specifically, are there any resources you can point me to or direction you can give me on where to start, taking into account that we need to implement tracking, persistence and versioning of workflows?
Based on your question, I'm assuming that you already have experience with WWF and are really just asking about how it interacts with Silverlight. The short answer is that it would not be noticeably different from how you would implement a WWF-enabled application in traditional ASP.NET. Remember that Silverlight is only a UI client that usually lives on top of a traditional ASP.NET web application. Your WWF-related logic and code would live in the ASP.NET layer -- not in Silverlight at all.
So if you already know how to make a WWF-enabled application in ASP.NET, all you really need to learn is how to wire up a shiny Silverlight interface to an ASP.NET web app. For that, you of course only need to hit up http://silverlight.net/, which you're probably already doing.
Good luck!
I am working with on an app that uses wpf / silverlight on the front end and nhibernate on the back end, and looking for some design ideas to address authentication; I was looking at Rhino Security which I think is pretty slick and certainly useful, but doesn't in and of itself seem to address authentication.
That said, I am looking for something of a technology agnostic overview of authentication design issues at this point. Does anyone have any links and / or experiences with an authentication design that is relatively easy to adapt to different common technologies.
Cheers,
Berryl
I am using an hierarchical RBAC pattern for my application. I am using the table design from yii for this - and it works pretty nice (in the first step we would like to use the yii rbac client to manage the authentications).
I'm looking at Silverlight architectures and RIA Services looks interesting, but I am a bit concerned about its prelease status and how the feature set will change.
We need our client app to be as responsive as possible over a slow network link, so a high priority is a solid sync system for pushing model state changes from the client back to the server. Will RIA Services help us in this regard or will I have to roll my own logic to do this ? Are there any other frameworks that can assist with this? Is the feature set involved in these requirements liable to change much in the next couple of months?
If it makes any difference, our frontend is 100% Silverlight, so we dont need to worry about exposing SOAP APIs from the server or anything like that. It appears to me that RIA so far is a bit more mature for Silverlight use. Is this correct?
I am using SL 3, .NET RIA and EF. Still trying to figure out how to load, and update data effectively and best in performance. Little information that I have so far how to improve the performance issue that I face. Still need more time to get these frameworks to be mature. Hopefully, there are more resources and insight in the near future.
My take is if you are handling very light data application, silverlight can be a good choice. Once you have loaded the application in to your machine, it is like loading application within your box.
I would look into some of the ORM's / IoC Frameworks which help create a separation of interests. A couple examples are Castle Windsor IoC, they have a sample Silverlight 4 application that utilizes the Castle Windsor Framework. Another common ORM for Silverlight is
BL Toolkit. These have been around for a while in the Java arena but are newer in the .NET area. They basically help to move the complexities of the relational data model out of the UI code and delegate it to the Framework.
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