views:

37

answers:

1

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

+2  A: 

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.

FelixMM
Thanks for the reply. I went to the link he posted. So that sounds like that covers the mobile portion of the web site. My bigger question is more about how a native iOS or Android app would work because I don't know much about those. Am I correct in assuming that an iPhone/iPad/Android/Blackberry app could access the same web services that the web app accesses? Is that a good way to go for building a native mobile app that is using the same logic as a web application?
Corey Burnett
@Corey: An ASP.NET MVC application would be a pure HTML/CSS/Javascript application. Most (if not all) of the program logic would live on the server, not the phone. So any phone that can surf the internet would be compatible. Granted, that may not be what you are looking for.
Robert Harvey
Yeah I think maybe I haven't described my situation correctly. There will be two web apps (either built with ASP.NET MVC or ASP.NET Webforms). One web app is for traditional desktop browsers. The other will be built for mobile browsers. Sometime later we might want to build a *native* app - something that you download and install from the iTunes App Store or the Android Marketplace. I am guessing that when we build a *native* app on one of those platforms that those apps could use the same web services that we built for the first 2 web apps. Does that make sense?
Corey Burnett
@Corey: Yes, it does, and you can use the same web services as data sources for both the web app and the mobile app.
Robert Harvey