Question

We have two WebApplication in one MVC solution, one for Desktop and the other for Mobile version.

The architecture looks like this:

• Model Libraray ( including repository and DB Model )
• Service Layer ( Business Logic )
• Web application Project ( views , controller, viewModels for desktop )
• Mobile web project ( Mobile views, controller, viewModel)

I added a service layer into this project http://www.asp.net/mvc/tutorials/validating-with-a-service-layer-cs).

as long as these two web projects have different controller but most common logic , which of following I can move to service layer.

• HTML Helper classes
• View Model validations
• Common functions

Thanks in advance.

Answer 1

First to answer your question of where to position those codes

1. View Model validations
   If there is no particular reason to use the service layer model validation I’d rather advise you to do model validation using data annotations within Model library. All you have to do is to add some attributes to your entities’ properties and things will work out of the box including validation messages (if you add validation elements using Html.ValidationMessageFor() or similar) in your client side view.

2. HTML Helper classes
   HTML Helper classes should be part of Common UI library if they’re supposed to be shared. They don’t belong in any of the existing layers, because all of them are presentation layer (web apps) independent. I suppose your HTML helpers will be presentation layer dependent hence a separate library would suffice.

3. Common functions
   Depending on where you need to use common functions, they may as well be part of Model library or Service layer.

How I structure my web apps

The following are written as layers. They’re of course separate projects in the whole solution so they become separate assemblies.

1. Objects layer – contains all common classes/enums/interfaces, general functionality and application model POCOs used by any layer; that’s why it’s referenced by all other layers

2. Data layer – has data access objects (that may as well be inherited from POCOs in the Objects layer) that are only used within this layer and perform mapping to and from application layer POCOs; There are also repositories in this layer hence this layer/assembly is referenced by the next layer (service)

3. Services layer – contain business logic and manipulate application model classes; gets data from presentation layer and uses Data layer to manipulate data in the backing store (wherever it may be – this is of course part of Data layer repository to communicate with the store)

4. Presentation layer – may be a web application or anything else; references Objects and Services layer so it’s able to communicate; any objects that are presentation layer only are also created here (special view models required by views but not by services);

All these mean that my Objects layer provides means of communication between layers by providing common classes that are used to exchange data between layers.

In cases where there are certain other providers I need to implement they may be part of a separate layer, but upper layering works for the 90% of all applications. A good example would be some common library that gets reused across different applications. Depending on what that library provides it gets referenced by those layers/assemblies that need its functionality.

In you case where you have two web applications, I would create a special layer named Presentation where all common HTML functionality would be and then reference it in both web applications.