i am using AutoCompleteExtender in my project.and i declared the webserive in BL LAYER.And exposing it to my project.but i dont know what to give service path for this extender.
it requires asmx method that not in the project.
Your web service should be in the client tier - and this can call into your BL layer.
So what I mean is think of our web service is a client facing chunk of functionality. The web service itself should not really implement any logic - your Business logic layer should.
So in your web service you would have (in psuedocode)
[WebMethod]
public string[] AutoComplete(string input){
return _businessLogic.AutoComplete(input);
}
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 have an application architecture which has following layers (or c# projects).
web front end (asp.net mvc2)
service layer (normal c# class library)
Model layer (normal c# class library with entities, service and repository Interfaces)
Data layer (implements repository interface defined in BLL and uses NHibernate)
ISession is opened per http request and its working fine.
Now, I would like to add wcf layer on top of my current service layer. wcf project plainly calls original service layer classes. But as soon as I do this, the session/session factory at asp.net becomes unusable/unavailable. Looks like, wcf is running in totally different context than asp.net. Hence I would like to move the logic of initinializing session factory and session management to wcf. How should I do it? and even before is it a good practice? one of the reason I would like to add wcf is because I want to expose the operations to other applications (which may not be http based).
Any help, blog post or book reference would be greatly appreciated.
Use Per-call instancing of NHibernate session. Check this article. It explains how to create attribute which will attach Session to current instance context.
you probably want to have WCF running in the same context as asp.net... try this article:
http://msdn.microsoft.com/en-us/library/aa702682.aspx
The application on which I am working has a web service exposing various methods. Most of these methods use WebOperationContext.Current to set headers up to prevent cacheing. This works fine when the service methods are consumed in AJAX via the generated proxy, but when I attempt to do the same thing from code-behind, WebOperationContext.Current is null.
Can anyone tell me how to confer appropriate call context on the method invocation?
I've developed a data access layer that grants the following methods to any subclasses:
List<DataObject> Select(int primaryKey)
List<DataObject> SelectAll()
void Insert(...)
void Delete(int primaryKey)
void Update(...)
I'd like for there to be some easy way I can wire them up to some kind of dispatcher that would look at the URL, pick out the type and present the CRUD operations as web methods in a traditional SOAP web service, generating the WSDL for them on the fly.
Something like:
http://Server/Customer/
or
http://Server/Address/
That would present the typical web service client test page we're all used to seeing, with Select(), etc presented as Web Methods. Is that possible in ASP.net? How would I go about doing this?
You should not use ASMX web services for new development. Use WCF instead.
In your particular case, see ADO.NET Data Services (renamed to WCF Data Services in .NET 4.0).
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.