From last one week i was searching for most suitable architecture for a new web application. To be honest i did web development for only 1 year (back in 2007). And from last four years i am working in C++. Now, suddenly i am assigned a task to search for best architecture for a new web application. During my search i cam across following 3 options:

Model View Controller

Model view Presenter

3 Tier Archi (Presentation layer <--> BLL <--> DAL)

What we are going to Develop

We are targeting towards the development of a social web application like facebook, twitter etc. Once we have launched the web version then we move towards the mobile edition of same application

What we will use

We will use ASP.net and C# under framework 4.0

Why I Post Question?

To be honest, i don't have experience either in web development or mobile application development, so the major purpose of posting this question is to get hep from some experienced developers/architects.

My Question:

I am looking for such an architecture that first allow me to start with web version and then allow me to provide mobile edition with less effort. With less effort i mean to say that I only want to develop two UI Layer two times (One for web and one for Mobile). I want my Business logic and data access layers remain same for both UI layers. Please help me in chossing appropriate pattern for above application.

What i did so far at my own?

I read all above 3 architectural patterns in details and have basic understanding of all three but still unable to choose appropriate pattern for me, secondly i didn't find any more patterns so if there are some more please share their names only

5 Answers
5

I would suggest ASP.NET MVC 3. The new Razor view engine and syntax is great. Also, it would be possible and quite simple to support multiple devices in a progressive manner. You can start with the base version and add sub-folders with corresponding views specific to each supported device and then modify the view engine to select a view based on the user agent. As long as the view model remains the same, the data/service layer does not need to change. ASP.NET MVC is also suitable for the development of a service layer and can be a viable alternative to WCF, especially if the service(s) are intended to be used exclusively by web applications. This is something to consider if you envision exposing an API to the web application.

What is important? Having modules compile to a reusable dll. If you want to get a little less specific, then you could call it a reusable interface. DLL or interface could be exposed through a service of course. In order to be re-usable you can't mix 2 different things in the same method. This is the "no duh" design that everyone likes to over complicate.

BTW avoid getting service-itis. If you are ON the server you will want to use the dll directly. Reserve the service for the clients. Avoiding the extra overhead of the service is a big deal if you want you'r website to scale to face book proportions. It's not wrong per-say, and could even be correct, but if your expecting a 1000 hit per second load, simulate that load and see what happens.

So my vote..... trash all 3!!!!! I've seen so much 3-tier where people just blindly stuff everything into 2 dlls (one for DAL, one for BLL) with 99% of the bll no more than a buffer with no logic. When really it should have been split into about 4 or more DLL's based on the functionality. These frameworks are a great way for morons to avoid cramming everything into a single DLL. That's about it.

Consider using a RESTful pattern for data management. When paired with some straightforward presentation logic and a relatively thin business logic layer, it can create a very powerful system that can easily migrate to new platforms.

I'd add my vote to use ASP.NET MVC 3. Additionally, since you have a mobile audience in mind, be sure to read a book or two on the topic, as there are tricks you can use to vastly reduce your work load in the long run.

For example, using unobtrusive javascript and "hijaxing," you can have some pretty spiffy javascript-driven stuff which degrades gracefully for browsers don't support javascript.

Also, if you do the front-end HTML right, you might even be able to avoid re-writing the view layer for different devices. You can literally just apply an extra set of CSS rules to change your elements' styles depending on what sort of device is viewing the page. A friend tells me that jQuery Mobile makes this sort of thing easier, but I've never tried it myself.