asp.net mvc作为一个宁静的服务和一个应用程序？

Question

Currently I am working on small application in asp.net mvc. It is a some kind of localization tool. Our clients login on our application and they can translate terms that shows up in our applications that they use. It is happens like this:

1. login to localization site
2. find and translate certain terms for example title for button in "Catalog" application
3. start that application(for example, "Catalog" application from 2.) and trough web services they update local database of terms with these that are translated

It is our old solution and that works fine. But now, I am doing refactoring of a translating tool application in asp.net mvc and I think, why we have separate logic(doubled) in mvc and in web services? Why we can't use only mvc as a web service...this way I have only one logic(fetching elements and updating) and we don't need to create wcf web service or something. And most important, I don't have mesh desktop applications with dependency on dll's in which I have this logic.

And now the question. What I can get from controller in mvc, except of views and JsonResults...can I get collections of my objects directly?

Or more plain question, how I can use asp.net mvc as a web services. What is your experience?

cheers Marko

Answer 1

It really depends on your needs. You can most certainly use an ASP.NET MVC application as a data service, but it sounds like you should tease out your shared code into a common library and reference that library in both applications. There are some things that web service projects provide that would be more difficult purely as a controller action. (de/serialization, wsdl, etc...)

Answer 2

It really depends on what will consume your web service.

For example: jQuery consumes JsonResults well because i can return complex objects (with collections, arrays, nested objects etc) from an action and have jQuery deserialize it back to javascript object for use in the clients browser. Of course you loose type safety with the serialization process but that's pretty expected in most REST/SOAP based web services. If you really need the type safety for the consuming application, stick with WCF (or similar).

I'd just create a flag to return an action as Json. I've noticed a few sites do it this way. Say you have this action:

    public ActionResult GetPeople()
    {
        IList<Person> result = svc.GetPeople();

        return View(result);
    }

..this action's result is normally rendered into some view. That's great, but if you want to use the action as a web service, you could simply change it to this:

    public ActionResult GetPeople(string ajax)
    {
        IList<Person> result = svc.GetPeople();

        if (Convert.ToBoolean(ajax))
            return Json(result);
        else
            return View(result);
    }

..so if your consuming app didnt mind the serialized Json then instead of invoking the GET request like this http://domain.com/controller/GetPeople (as a browser would to get the View), you'd just add the ajax flag like so http://domain.com/controller/GetPeople?ajax=true to return the Json. A more appropriate flag might be 'json' instead of 'ajax' - 'ajax' is common because this method is used to support downlevel browsers for actions that may optionally be invoked with ajax.

I've been thinking of adding this to my mvc app for a while but i don't like the idea of modding every action with this flag and add more if statements. My idea is to create a custom attribute to decorate actions that you want this functionality for and the attribute dynamically adds the extra flag and conditionally returns the model data as Json rather than what's originally specified. Give it a go.