Want some architecture input to help with current requirements and future (unknown) requirements :-)

Question

BACKGROUND: I am starting to architect a web project using asp.net mvc.

I'm going to use a very common architecture where I have the following layers:

1. Service
2. Biz
3. Data
4. Domain

The Service layer interacts with the Biz, Data and Domain layers. The mvc controllers will have the service layer injected into them using a DI framework. The controllers will need to be aware of the Service layer interfaces and will reference the Domain objects (POCOs).

The front end will be HTML5 + Javascript.

I have been told to keep in mind we need to expose portions of this website to mobile devices. The portions to expose via mobile devices is to be defined :-).

When rendering the site I can simply have a mobile layout that renders to a mobile device. But one thing management told me is mobile users might want additional functionality the website doesn't expose.

Maybe they want to access a feature that only a native mobile application can provide. Hey, I don't make up these requirements, this is what I was told :-).

THOUGHTS: My service layer is the gateway to storing objects in my database.

For any potential native mobile devices I was thinking about using the Web API to wrap my service layer.

What I want to do NOW is focus on on my asp.net mvc application and only worry about native mobile apps when those requirements become more defined.

QUESTION: would it provide any benefits to code the Web API layer now and have my mvc controllers use it?

---

Pros for creating the Web API now

1. It will be coded and ready if / when a native mobile app comes online.

Cons for creating the Web API now

1. It is overhead that is not needed, especially if I host the WebAPI in a seperate process or another site besides my original asp.net mvc site.
2. The technology is fairly new and enhancemens will be forthcoming. If i wait until later some of the issues will be fixed.
3. Who knows, my users may never want a native mobile device and the feature is never utilized.

4. The code becomes more complex because of having to maintain the web api layer now.

   I'm looking at not worrying about the Web API layer for now and simply coding it when necessary.

   Typically I don't worry about writing for functionality that is yet to be defined. But I thought it might not hurt to ask, you never know what some brilliant maverick programmer is doing out in the wild :-).

Answer 1

I would consider your WebAPI layer to be a (non-graphical) user interface layer, equal to the MVC layer.

Put as much of the non-UI code in the Service layer (or below) as possible, and write the MVC layer to access it, keeping the MVC controllers as absolutely thin as you can.

Then, later, when you want to provide access to mobile (or other) clients, write your WebAPI layer to access the same Service layer, keeping the WebAPI controllers as thin as possible, exposing only the features you want to expose through the API.

I would not bother writing your MVC layer to access the Service layer through the WebAPI. I don't see the point, as long as all of the common business logic is in the Service layer; You don't really gain anything (except another layer of indirection).

The WebAPI piece will be relatively quick to write, assuming you've written your Service layer well during the MVC-building phase.

Answer 2

I totally agree with the YAGNI approach, however, I see the YWBFI or You Will Benefit From It (just made that up) "principle?" sneaking in. Accessing data / objects from a Service layer through a URL "schema" will give you great flexibility, and the Web API is literally just some attributes you put on your existing / highly usable classes and you get great RESTful routing, which again provides great flexibility.

I would build as much into an API type access layer, and then each client can decide for themselves how to implement the API, including your own apps.

Since utilizing the WEB API functionality is so simple, I don't see how much overhead it could really add compared to the benefits you'll receive both short term and long term.