Home/ Questions/Q 8531281
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T09:26:55+00:00

I am working on a web application and later we have plan to develop

  • 0

I am working on a web application and later we have plan to develop and make available its mobile applications as well. I am not a very experienced but just based on my understanding planning to have this architecture:

  1. MVC Web project front end which will directly communicating to WCF
    services.
  2. Server side validations will be done on MVC model using data annotations then data will be passed to WCF layer. Security using Customer membership provider will also be implemented in MVC.
  3. WCF layer will work like a business layer as well. Where required it will be communicating to DAL which is a class library.
  4. DAL using EF will be communicating to SQL Server*

Questions please

  1. is this architecture good ?
  2. is it good to use WCF as business layer and services layer ?
  3. on which layer we should implement which pattens ?
  4. for data validations and security is MVC correct place ?

Thanks

Edit
5. Is it good regarding unit testing ? or for better testign I should do some changes ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What you’re describing is a pretty modern and good Microsoft server stack.

    ASP.net MVC is a good for you’re web UI. If you’re going with asp.net MVC you should also look into asp.net webapi (new) for the business layer.

    http://www.asp.net/web-api

    http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx

    SQL Server and EF are fairly standard. The other option is pure T-SQL if you need ultimate control and are comfortable with straight sql.

    One side benefit you get from separating your web UI (MVC) from your business layer (web-api) is you could separate the roles and scale independently even if initially they happen to reside on the same role/machine. Also, the client side html/javascript code could do ajax style calls to the web-api. For that reason, you would want to “register” (config) the end point of the web-api server. If you scale/move it later, there’s no code changes – you code with a clean separation from day one.

    Mobile devices (if thick apps) could use the web-api directly. Unless the mobile app is a hybrid mobile app using an embedded brower/javascript solution, then its just a small form factor consumer of you MVC web UI.

    For testing, you can self-host web-api in it’s own command line process and mock out the data if that’s feasible. That would allow you validate the web UI without a backend. By having a business layer (exposed by web api) you can also validate the backend & logic (should be the majority of your logic) independent of the UI.

    • 0