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:
login to localization site
find and translate certain terms for example title for button in "Catalog" application
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
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...)
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.
Related
I'm trying to understand how I should use the MVVM pattern for a CRUD operation. Currently I have methods in my API controller such as below. My question is: using MVVM pattern, should I still build my api like that (e.g., accessing DB)? Or should it be changed? If nothing changes, in which case I would implement ViewModels and how they should be managed by the API? I made some researches but it's still not clear for me.
public IHttpActionResult GetProduct(int id)
{
var product = _context.Products.SingleOrDefault(p => p.Id == id);
return Ok(product);
}
[HttpPost]
public IHttpActionResult CreateProduct(Product product)
{
...
_context.Products.Add(product);
_context.SaveChanges();
return Created(new Uri(Request.RequestUri + "/" + product.Id), product);
}
I think part of the problem is that you don't understand the role of MVVM in a web application. To understand, you have to look at a web application as composed of two separate applications--the server side, and the client side.
Server side, the pattern being used is MVC (not surprising, it's called ASP.NET MVC for a reason). If you're trying to fit your understanding of MVVM around the MVC pattern--don't. It doesn't apply. The MVC pattern on the server is simple to understand and implement; don't try to crowbar any MVVM into it. Just design your server side code using the server side pattern.
Client side is a different matter. By default, ASP.NET MVC using Razor pages renders your HTML on the server and delivers it for display to the client. And, typically, that HTML is designed to respond to users interaction with the page by posting back to the server. Your controller methods interpret these postbacks, perform the required logic, and render the correct razor page in response. But this isn't the only way to write a website.
More and more common, people are designing Single Page Applications. These use ajax callbacks to send the result of user actions back to the server, and then process the response. Server side, these requests are almost always handled through a WebApi controller method, not an ASP.NET MVC controller method. The request comes across the wire as ajax, and the result is usually returned as ajax. No HTML gets rendered. This is where MVVM comes into play.
Client side, these web pages typically use a javascript MVVM (ish) framework, like knockoutjs or angular. The response json is used to update view models that are bound to HTML elements in the web page. These frameworks handle synchronizing updates and user actions between the UI and these view models, just like Bindings synchronize updates between the UI and your view models in WPF.
Simply put, MVC is its own thing, and MVVM usually only exists within the client side of a website, and usually only when the website extensively uses ajax callbacks instead of postbacks.
And, to answer your direct question, if you're using MVVM on the client side, using ajax calls to perform your CRUD ops, you should design your WebApi controller methods to Post/Get/Put/Delete your data.
Personally, I always use the Repository Pattern for anything to do with CRUD operations, such as interacting with an entity in a database.
I would create a separate class called "ProductRepository" and put all the methods to Get, Create, Update, and Delete a Product in that class. This way, only your Respository cares about the details of interacting with the database and performing the CRUD operations on it. Your entire application should not care about how this gets done, only your Repository class. This is something known as the Single Reponsibility Principle. It is part of the "SOLID" principles of design and architecture.
Then, in either your Controller or ViewModel or where ever you need it to happen, you just have to instantiate the ProductRepository and use its methods throughout your application.
If you use a separate Web API for your service layer and data access layer, then you don't really need MVC. You just need a front-end framework to consume the Web API URLs, like AngularJS or any other JS framework of your choice.
If you want to use MVC, then you don't really need Web API. You can just build your service layer and data access layer into the MVC application, or build them as separate projects (class libraries) and include them in your overall project solution. It all just depends upon how you want the architecture to be and how complex you want to go with it.
But either way, a "ProductRepository" should be involved -- whether it is in your Web API (if you go that route), or in your MVC project (if you go that route). The ultimate goal is to have separation of concerns. You want to separate your business logic layer from your data access layer. You don't want to be making direct calls to the database throughout your entire application. That will result in code that is very tightly coupled and hard to test and maintain over time. If you ever change out databases in the future, you only want to update one place in the code, instead of many places.
Hope this helps you out some! Best regards and happy coding!!!
Please let me know if the premise of my question even makes sense...
I have a WSDL file from an existing (locally served) web service. I would like to "wrap" that web service with a Web API so I can easily make RESTful AJAX calls to it. If I add the WSDL as a Service Reference, I can write controllers and make calls.
I guess my questions are two things:
Is there some easy way to expose all the WSDL actions without manually writing controllers for each one?
Is this even a good idea in concept? Is there a better way to create a nice client AJAX relationship that I'm not thinking of?
Yes, it is a good idea in concept. Abstracting the ASMX for the clients and providing an easy REST based endpoint is good.
I'm assuming the ASMX is a separate component in itself and doesn't share any Middle-tier code with your Web API project.
It is okay to abstract out the ASMX.
As for an easy way to expose all the WSDL actions as controller actions, how many Web methods are we talking about?
Typically we only have a single ASMX web service with a few web methods. (5-15)
If you have just a few, creating a single controller with 10-15 actions should not be that painful.
On the other hand, if you have unmanageable number of web methods, you might want to think of Text Template files (.tt) to generate controllers out of 'Reference.cs' files. (proxy file) i don't think there are auto-tools to convert asmx to a web api controller.
i have found it easier to hand-write the web api controller due to the nitty-gritty of the request/response types, return types, [FromBody] [FromUri] attributes, HttpPost, HttpGet attributes, and of course the action definition itself.
The text template logic could get error-prone trying to figure out HttpPost actions vs. HttpGet etc.
Also, a good controller will end up having injected dependencies for Data Access, Caching etc. and you would want direct control on the class, rather than being created by an automatic tool.
I'm trying to build my first enterprise ASP.NET MVC 4 web application, and I'm having some issues figuring out the correct flow of things.
Let's say I have a view Clients.cshtml, which has the corresponding ClientsController, base class Controller.
I want the Clients view to display a list of all clients in the system.
Because of Separation of Concerns, I believe the correct place to handle such a request would be an ApiController, not the Controller itself, which I believe should be more or less restricted to UI tasks. So, I add the method getClients() in the ApiController which will return a JSON object containing all the clients.
Now, how do I consume this from my View, or my Controller?
A way, I believe, would be handling it using javascript; when the View is loaded, I call the ApiController using jQuery and such, and display the results asynchronically.
But I am not sure this is the correct approach, is it? I believe it is one approach, but I'd like to know alternatives, or better (more conventional) ways of handling this.
Thank you
It isn't necesary to develop a Web API, if you won't use that API in other web apps or mobile apps.
A Web API is intended to be an easy way to have a single core for several consumers, for example android apps, iOS, web apps or even custom third party consumers.
So if your app won't be used that way you don't need to use API Controllers.
If you want to separate concerns, I recomend you to create a different project (a Class Library project) in the same solution, that project would be your internal API. Then your MVC project will consume your internal API, trying to keep your controllers as skin as possible. I recomend you to read this article (it's for Ruby on Rails, but all the concepts apply to MVC .NET).
It seems like what you're looking for is a way to surface the same data to both your views (server-side rendering) and your javascript (through a JSON API).
There are multiple ways to go about this. As you mentioned, you could create a separate API controller, but in my experience this is a little smelly once you grow beyond a handful of API calls. Ideally, you'd want your API to have the same RESTful architecture as your normal controllers, which means you'd be repeating a lot of the same logic for adding, listing, and removing objects.
A good alternative I've found is to allow each controller to return either a view or JSON, depending on the format of the request. This could be expanded to include XML, CSV, or any other formats you'd like to consume from a client. There's an excellent blog post by Michael Morton about this approach. It may not be exactly what you're looking for, but the end result looks something like this:
public ActionResult Index()
{
List<Client> clients = db.Clients.ToList();
return RespondTo(format =>
{
format.Html = () => View(clients);
format.Json = () => Json(clients);
});
}
I am new to Web API and I have a Class Library I would like other applications to access via an ASP.NET Web API site.
The problem I have is that I do not know how to call methods that have multiple input objects some of which are custom entities (they all have several variables inside them and come from the Class Library which I don't have access to change).
Here is an example of one of the methods my API Controller
public bool Process(IBusinessObject businessObject, BusinessValidationObject businessValidationObject, IList<string> messages)
{
//Code to call Class Library is here that requires the 3 inputs
}
Is the above bit of code a valid API method?
I would like to call that method from another ASP.NET Web Application (an MVC application in another solution which will be installed on another server). I have had a look at the Web API Client Libraries but I can't see a way to pass in multiple objects.
Anyone have any ideas?
You can only post one complex object.
A solution might be to create an object that contains all three of the objects that you are trying to pass.
I have many webmethods in one asmx. I need to perform licence checking before some of this webmethods invoked. I can insert following code to each web method that needs checking:
if (!AllRight())
{
// badRequest
return;
}
Or I can insert complex filter to HttpModule to detect webmethod by URL.
I need something like attribute for webmethod and place where I can handle it.
Is there pretty good solution?
IMO, both of these options are good. Using HttpModule is a good approach - detecting web service call by parsing url is really simple - in short, you are looking for particular asmx (and handling WSDL request). If you want to do selective license check then do simple method name sniffing in URL (as opposed to decorating methods with attribute).
Apart from above options, you have couple of alternatives
Uses some Aspect Oriented Programming frameworks (for example, PostSharp) to inject license checking code by using attribute to decorate the method.
Do it at handler level. Essentially, implement a IHttpHandlerFactory and use it for your asmx end points. The implementation will wrap WebServiceHandlerFactory (or ScriptHandlerFactory in ajax cases) and will return a handler that wraps over the handler object provided by underlying handler. But frankly, this is a brittle solution and essentially same as HttpModule but more complicated.