I would like to create an opensocial application. I have read about how to do this on the client side, my question is what is the most appropriate server side technology to use? My idea requires persistent data and business logic that should be stored and executed on a server. I have some familiarity with creating full blown web apps in ASP.NET and Ruby on Rails. Can I leverage those to build a complete opensocial app (with an iframe or something like that) or do I need to create only a back end using one of those technologies that will be accessed by javascript?
We're using Apache Shindig (Java) for a live project at http://www.lonelyplanet.com/groups
The website hosting the gadgets is written using Ruby on Rails, and all the business logic, data persistence etc is handled there.
We've injected custom handlers into Shindig to proxy everything to the Rails app using REST services. You can make Shindig do as much, or as little as you want. We've got it doing very little, and keeping all the app logic in the parent app hosting the main site. Shindig just serves up gadgets and handles security etc.
Related
I'm new to the .net application. am trying to develop an application for Accounting Purpose. Am totally confused that how can I use the design pattern, MVC is preferred. I have to use this app both in Desktop and as a mobile app. App should be more secure.
So please guide me how to design the project. Can you please suggest any examples?
WebApi + MVC is good option I think but for this, should I create 2 solution for both API and MVC?
should it work smart phone as well as desktop?
Database-PostgreSQL
Application will have two parts:
Part I – Accessible to the client through the web page
Part II – Back-end accessible only to us (Company) where all the processing is carried out. Perform the initial setup once the client is registered – create the account in the accounting software and create the chart of accounts
Review and process documents
Accounting – the entries will be passed in the application and will be exported to the accounting software
First of all you can find many tutorials out there on the web about creating a ASP.NET MVC project with Web API.
This can be achieved in one solution as you will see in tutorials.
Example: Getting started with ASP.NET Web API
For the desktop and mobile support, I would like to refer to use Responsive Design. Using a library like GetBootstrap you can create websites that change their content dynamically for each type of device ( desktop / tablets / smartphones / ... ).
Now-a-days everything is mobile. So if you are developing something both for Web and mobile app, API has to be the first and only choice.
The reason behind is that--- More or less what Web shows, APP should also show that, but the layouts or UI are different(here comes the client-side). Moreover if APP needs some extra API, I do not think, that would be much overhead if certain extra APIs are written for the APP. Essentially One API codebase suffices both the paradigms.
It is always a good idea to seperate Client-side architecture with server-side architecture.
I would suggest to seperate the client and server(API), and that would be in best of interest.
Your .net application may serve as client side with MVC pattern where M can call API services and C as usually manages the business logic and V displays the results.
You can write API services(server/backend) in .net, nodeJS, PHP, GO any technology which can manage talking to servers. There also you can create certain architecture or flow of your requests.
Hope that helps
I am currently starting a massive web app project, and one of the requirements is that down the line I may be required to allow an iOS and Android app to interface with my application, I figured the best solution was to create a RESTful API and have the web application interface with it. However, my coworker who does front end development is unfamiliar with using a javascript framework such as backbone.js (more of a library I know), ember.js or angular.js. Since we're using asp.net I figured that the I could handle authentication and routing using asp.net MVC, delivering seperate views depending on the route, and he can handle the data manipulation only, However, I can't seem to figure out how to seperate routing from the javascript framework, I've looked into ember.js and backbone and both of them seem to require routing to be handled on their end for it to really work.
Does anyone have any idea how to implement data manipulation without the need for routing?
What you are describing is generally called API oriented architecture, meaning you have a RESTful service on a back-end and rich client-side application on front end.
The point is, it basically does not matter what technology you pick up on server. It could be anything: ASP.NET MVC, Web API, Express.js or Django. As soon as it's really RESTful and pure. By purity I mean, it deals only with data, no serving of HTML or something.
Server just specify the interface you work with data,
GET /invoices // get all invoices
GET /invoices/:id // get invoice by id
POST /invoices // post new invoice
If you confident with .NET, WebAPI is probably good choice. Typically you would prefer JSON output, WebAPI could handle content negotiation for you.
Now, the client job is to consume the API data and dynamically create HTML in browser. A lot of options now: Backbone.js, Angular.js etc.
Please be aware: client side routing and server side routing are completely different things.
Server side routing: routes particular HTTP request to particular controllers action (or any function).
Client side routing: detects the URL change and triggers corresponding JavaScript function to handle change. Client side routing is vital for SPA (single page applications). You can find a bit more information on SPA on that blog post.
Have a look at KnockoutJS, which would allow you to use ASP.NET MVC for routing or another JavaScript library like sammy.js (just for routing) or Durandal (for routing and navigation).
Note: Durandal version 1 used sammy.js internally, but version 2 has a custom routing engine and no longer uses sammy.js.
I am supporting an ASP.NET app, which is installed on a web server and a VB6 app installed on a different app server. There is code duplication in the VB6 app and the ASP.NET app. I want to use some of the code in the ASP.NET app in VB6. I believe I have three options:
Expose the required functionality in an ASP.NET web service. The VB6 app will consume the web service.
Rewrite a small section of the vb6 app in .NET and extend the asp.net app. This will eliminate some of the code duplication.
Setup a class library for the ASP.NET app. Install the vb6 app on the web server. Expose the required functionality from the class library in a type library.
Which option is best? I believe option 2 is best.
Option 1. That leaves your shared, already-tested code on the most modern platform.
This is very hard to answer, as it varies for each company and each situation.
As a general rule, I'm very much in favor of using web services where possible, especially if multiple applications are using the same logic for the following reasons:
If I have to change the logic, I can do it in one place and fix all apps that depend on it
The same can be said for database connection strings, etc.
A bug fix can also often be fixed in one place.
I've had difficulties with a particular database that I need to deal with, where the vendor's updates tend to break their .NET adapter. Twice I had to modify/recompile a ton of apps to resolve this. Since then, we made it a policy to connect to that DB only via web services, so I'll only need to update one app in the future.
When developing mobile apps, the simple fact that we already had all our code in web services makes it that much easier to write apps that are strictly UI and leaving the business/database access logic as-is in existing web services.
All of those are pretty much "Standard" arguments for the SOA approach.
All things considered, my first recommendation, not knowing your specifics would be option #1.
There is a fourth option - a total rewrite of the VB6 app, if it's feasible, and if you can convince those who control the budgets and time allotment. Even with that, you can use the Service Oriented Architecture and split much of the logic into web services.
I am in the planning phases of building a new ASP.NET website. The website is really a transactional web application where the users will log in and perform basic CRUD data operations. For right now this website will be accessible through a traditional desktop browser and a mobile browser. For the mobile browser we will build a separate scaled down version of the site.
In the future we may decide to create native mobile applications for Android or iOS devices also.
So the question I have is what is the best way to design the system to easily support that? Here is what I am thinking. I am thinking of building out 3 tiers to the site. The back end will be the database - SQL Server 2008. We will use stored procedures for all data access. The middle tier will be a web services tier. This tier will be built using RESTful web services and will contain all of the business logic. These web services will provide access to the database. The front end will be built using ASP.NET. The front end will only contain presentation logic. These tiers will actually be deployed on physically separate servers.
Then I am thinking that when we decide to build a native Android or iOS app that we could build those apps to simply call the same RESTful web services that the main site is calling.
Does this seem like a reasonable approach? The only thing I can think of is that the way we are building it right now the web services would be behind the firewall and would not be accessible to the outside world. When we want to support a native mobile app then we would need to make the web services accessible to the outside world.
Any thoughts? Does this seem like a good approach for building a high availability, high usage web app that needs to support native mobile apps in the future?
Thanks,
Corey
I'm with Rober Harvey there. With ASP.NET MVC you can make the presentation site in no time, use as Models your web service; with the link that he gave you, set the site for mobile browsing, and use the web services for the mobile apps when you build them.
For me it looks like a good plan. Regarding the web services being public, you can protect yourself by implementing API keys in the web service, so only your apps can use it.
I'm pretty new to Silverlight/RIA/Asp.Net thing, and I'm trying to figure if an Asp.Net website is required (for hosting the app) if I wish to use RIA services with Silverlight?
You could use a Web Application for hosing the RIA services in which is a compiled version of a Web Site. This is a distinction made by Visual Studio for different types of web projects but that might not be what you mean.
Really though RIA is just web service that takes a certain set of parameters. You technically could use PHP and generate the same content although that seems like it might be a bit of work unless there are frameworks that already do this.
Your RIA service will need to live somewhere online though. You don't need a website with web pages but you will need to run the service in a web server like IIS and that means it probably needs to live in a web site, even if the website doesn't have any web pages.
No, you can not use RIA services without an ASP.NET application. While it is true that you can create the backend data service with PHP (or a number of other web technologies), that would not be making use of RIA services.
The basic idea of RIA services is to provide a super simply means of plumbing your data classes through ASP.NET. Mostly it is used in conjunction with an ORM and additional metadata classes in your web application. You then provide a service to manipulate your data. When you compile the solution than the work you did in the web project gets pushed into your Silverlight application (through code generation).