locked
Asp.net MVC with webservice as model RRS feed

  • Question

  • Does anyone have advice or tips on using a web service as the model in an ASP.Net MVC application? I haven't seen anyone writing about doing this. I'd like to build an MVC app, but want to use webservices outof business layer as model as we are moving towards SOA where we have to expose services for others to consume

    Cheers
    TA
    Wednesday, August 19, 2009 7:21 AM

Answers

  • Difficult to show like this in text, but I will try....

    VIEW

    PRESENTATION_MODEL

    CONTROLLER (aware of view, both models, and business layer)

    PROXY (returns business model or domain view) - This effectively hides that there is a service call from the controller, and joins MVC to backend logic (remember to use interfaces!!!).

    SERVICE

    DOMAIN_MODEL

    BUSINESS_LAYER

    DATA_LAYER

    DB



    Not sure if that makes any more sense, it needs more dimensions but you really need to separate the two layers of MVC, which is associated with presentation, and back-end business logic, which is associated with representing business or domain rules, and domain models.  From that point down, as the called of that logic you shouldn't need to klnow anything else, and the business logic should in no way give you any hints to the implementation in the data layer.

    Hope this helps,

    Martin.

    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Friday, August 21, 2009 1:08 AM

All replies

  • That really doesn't make sense.  You wouldn't use the web service as the model, however you could easily call the web service from the controller and populate a model with the data it returns.

    Is there a specific question you have regarding this?

    Thanks,

    Martin.
    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Wednesday, August 19, 2009 11:56 PM
  • Thanks for replying.
    I am desiging a system where customer wants to implement SOA as well as MVC.
    As per my understanding, model is the business logic layer out of MVC pattern.
    So if i am exposing my business layer using a service, i though that service will act as a model(or an interface to a model).
    Hence i carved the layered archiecture as

    -----
    View
    -------
    Controller
    -------
    Service
    --------
    Model
    ---------
    DAL
    --------
    Database.


    I can't think putting a model above service layer, as it wouldn't serve any purpose.
    As i am starter in this, i may be totally wrong.

    Can you please guide me to any .net sample which implement asp.net MVC and is having business layer exposed as service.

    Looking forward for your response
    TA
    Thursday, August 20, 2009 5:18 AM
  • The controller is where you need to put the service call, as this is where the controlling logic resides.

    I have seem implementations where the model populates itself, personally I think that this is bad form, since you're mixing business logic with storage, which isn't the most maintainable of approaches.

    A service is simply put, an interface into your business logic, so you would call this as you would normal business logic, and should be able to do so in such a way that your calling code need not be aware that it is calling a service (and you can disable the service call, and connect directly to business logic if you so desired)

    I think from your discussion above that you're suggesting that the service is binding the model from the database to the model used in the MVC for presentation?
    If that is the case, this is a very tightly coupled solution, meaning that it would be implemented in such a way that the presentation layer is tied directly to the database schema, so no real need for layer, as you have undone the benefit you would get from them.

    The way do do this is that you call your business logic that returns a model to your controller through your service (or not, as they case may be, see above)  Personally, I would then map that call into a presentation model, so that can change, or be abstracted away from the model in the business layer.  This breaks the dependency, as the controller performs the mapping, using interfaces for the model.  The logic inside the business layer and down to the data layer needs to be encapsulated, so that mapping between the data layer and business layer can be broken apart and re-mapped if that should be required, but should in no way affect anything above it, or how the controller calls the code.  Assuming that is, that the change is non breaking, i.e. if it is required to be shown in the UI, and stored in the database, then that is going to change everything, so would be like a major version upgrade.

    There isn't really anything special about this at all.  If you understand that calling through a service to a business layer, instantiated through some proxy to encapulate the fact that the service is being used, and you understand how MVC model works, you attach the call from the controller to the call into the proxy, and you have the completed flow.
    Obviously to make the system SOA, you will need to ensure that the logic is encapsulated, and does not bleed across into other logic, as this will result in heavy calls, and unmaintainable code.

    I hope that this helps you.  I know I have not given you anything other than starting points, but the key areas of interest are:
    - MVC;
    - Encapsulating Service calls;
    - Encapsulating business logic;
    - Service calls and returning data using DTO object versus simple types;

    Take a look at www.dofactory.com for hlep on patterns that might assist.  Look for Martin Fowler on patterns such as MVC / MVP.

    I could check on google for you, but that's half the fun of researching isn't it?

    Cheers,

    Martin.
    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Friday, August 21, 2009 12:46 AM
  • Hi Martin,

    Thanks for your reply.

    So you mean to say that stack should be like

    view

    ---------

    Controller

    ---------

    Model

    ----------

    Service

    ---------

    Business logic

    ---------

    Dal

    -----------

    Database

    ---------

    Am i correct.i tried googling for this kind of implementation but couldn't find it,though i did get MVC and business logic exposed through service seperately, but then confusion arises about model as a business layer Vs service exposing interface for a business logic layer.

    The only thing which i can't understand here is how putting a model above service layer will help in decoupling.
    It would be great if you could throw some light on that ,through few lines of code.
    Anyways thanks for your answer.

    Cheers

    TA

    Friday, August 21, 2009 1:03 AM
  • Difficult to show like this in text, but I will try....

    VIEW

    PRESENTATION_MODEL

    CONTROLLER (aware of view, both models, and business layer)

    PROXY (returns business model or domain view) - This effectively hides that there is a service call from the controller, and joins MVC to backend logic (remember to use interfaces!!!).

    SERVICE

    DOMAIN_MODEL

    BUSINESS_LAYER

    DATA_LAYER

    DB



    Not sure if that makes any more sense, it needs more dimensions but you really need to separate the two layers of MVC, which is associated with presentation, and back-end business logic, which is associated with representing business or domain rules, and domain models.  From that point down, as the called of that logic you shouldn't need to klnow anything else, and the business logic should in no way give you any hints to the implementation in the data layer.

    Hope this helps,

    Martin.

    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    Friday, August 21, 2009 1:08 AM
  • It seems that you want to represent this :

    UI
    UI LIght Process
    Controller (Who will instantiate a proxy to let me connect with my down Interface layer)
    -----------------------------------------------------------------------------------------------------------
    Service Interface
    Business Layer
    Data Access Leyer
    -----------------------------------------------------------------------------------------------------------
    DB

    But my question is: are you willing to use MVC with this layer distribution ?¿¿?
    and is there any example or how to use MVC/MVP interaction with my layers ¿?¿?
    If you feel this post was helpfull in any way to you, please mark it as answer. Sebastian
    Friday, August 28, 2009 1:39 PM
  • Hi Sabestian,

    Yes, we should distribute it in the layered form as mention by you.
    The example which you are asking for is here http://www.codeproject.com/KB/aspnet/aspnetmvc_bugtracker_v4.aspx
    Hope this answers your query.

    Cheers
    TicArch
    --------------------------------------------------------
    If found it useful, please mark this as answer
    Monday, August 31, 2009 8:46 AM
  • Hey everyone,

    Interesting topic, at least to me, as I'm looking at the same issue.

    I would think that a call to the webservice would be in the Model. Looking at the picture below (did a search on google with terms mvc and model) we see that data is obtained from the database via the Model. Substituting the database with calls to webservice(s) would be the same concept.

    The Controller acts as the mediator between the Model and View. I would think putting the webservice calls in the controller would add another level of complexity. Just my thoughts. rtt

    Thursday, December 3, 2009 1:51 PM
  • I have written quite a bit about this over on DotNetSlackers.com with a great deal of detail dedicated to the migration from a simple MVC direct to data (linq to sql) with several refactorings (each refactoring is a new article) that works its way towards exactly what you are talking about that allows an MVC front end with a distributed business layer capability built in.  Here are the articles.  

    Simple MVC: http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange--Three-Tiers-to-MVC-Hooray-A-simple-MVC-application.aspx

    Logical Separation: http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Three-Tiers-to-MVC-Hooray-Logical-Separation.aspx

    Physical Separation: http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Three-Tiers-to-MVC-Hooray-Physical-Separation.aspx


    Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net
    Saturday, December 5, 2009 9:58 PM
  • To obey the MVC pattern and its separation of concerns, calling the database must be in the model. And if this web services retrieves or updates data it should be at the Model level.
    Thursday, August 2, 2012 9:24 AM