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.
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!!!
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);
});
}
Whats the best way to implement this.
I am building application that will be hosted as a web service. This app takes an employeeID and returns an employee object that contains lots of info regarding the employee. (name, status, full-time/part-time, etc)
I want the two existing apps we have (and more to come) to be able to call a method that the web service will have and return the employee object. (also at time this web service that returns the object may have new fields added to it - Pay rate, etc)
How would I go about creating a new object from this web service reference in the existing applications.
Would I decalre it like Dim Employee as new emp_webservice.employee ?
And then be able to use this object within the app? Or would the better practice be to also included the same class files? It seems like this would not be the way to go, since if I make a change to that class I then have to make it in all places
Thanks for any clarification on this.
When you add a reference to a web service in a .net application, the objects exposed by that web service exist in the namespace that you created for that web service when it was added to your application.
So, any reference to classes from that web service would need to reference the namespace for that web service, as you have indicated. You could also have an Imports WebServiceNameSpace if you don't want to fully qualify every class.
You can't really include the class files if you are using the automatic web service interface generation functionality that VS.Net provides.
Also, if you change properties in the web service, those updated properties won't be propagated to the client until you update the web service reference in your project.
Finally, if you want to add methods or additional properties to the web service classes on the client side, you can use Partial classes.
For example, let's say that the web service only provides an hourly pay rate, but I want to show a weekly salary in the client. I can extend the web service class as follows:
Namespace emp_webservice
Partial Public Class employee
Public Function GetWeeklyPayRate() As Decimal
Return Me.HourlyRate * 8 * 5
End Function
End Class
End Namespace
Consider 3 modules/classes in an ASP.NET Webforms application.
I need a web service for each of them, where each web service contains only one function.
Should I group them into one web service class, or should I keep the one web service for each class?
If they are related and need to be exposed for consumtion by a single client you could create one webservice and call this an API. This means you and your client maintain/consume a single webservice.
If they are clearly unrelated, separate them.
Group them in one class (the base webservice class). If it's needed you can branch from here and instantiate more complicated classes, or even call external libraries (for example if you have a data layer to call)
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.