MVC Best practices when all methods come from a web service - asp.net-mvc

Hi we have a third party application that exposes a web service for use in building websites. It handles createing sessions , getting product data, shopping cart, and check out calls to the database. I am new to MVC and my question is how do I work this webservice into my mvc site i am building, I want to take advantage of testing as well. I can not change the access to the database, I have to use the web service.
Thanks!
Jon

I usually deal with the data access using a services pattern. In your case I'd have an interface like IProductsService with the usual methods GetProducts(), GetProduct(id) ... and so on. By coding against that interface your controller will not care about where the data is coming from, so you would declare and use your dependency as
private IProductsService _productsService
...
IEnumerable<Products> products = _productService.GetProducts();
This comes quite handy for testing purposes too, as with IoC you can inject a different service (one that returns a hardcoded list for example) depending on your test cases. Eventually if you guys switch to a different strategy and access the data store directly you only need to create a new service, implement the interface and inject that one instead.

Related

Using Web Services with EF Code First approach

I have developed some MVC applications by using Entity Framework code first approach and now I am developing a new application that will also use web services for mobile applications that we will create. So, I have trouble about the issues below. Could you clarify me please one by one regarding to the issues?
Which web service technology should I use i.e. Web API, WCF, etc? (I am using MVC5 and EF version 6 in my project)
Can I use the same CRUD methods for my web application and for web services? If so, which modifications should be made on the methods and on the other fields i.e. models, etc?
For a current MVC application where EF code first approach was used, is it better to create a new methods for web services or should the current methods be updated by adding ability to support also web services?
Thanks in advance...
I highly recommend to use Commands and Queries. It's covered in this and this articles.
The Command is simple DTO object, and it could be easily sent over the network. In this case you have control over the fields and behaviour you want to make public.
Because commands are simple data containers without behavior, it is
very easy to serialize them (using the XmlSerializer for instance) or
send them over the wire (using WCF for instance), which makes it not
only easy to queue them for later processing, but ot also makes it
very easy to log them in an audit trail- yet another reason to
separate data and behavior. All these features can be added, without
changing a single line of code in the application (except perhaps a
line at the start-up of the application).

Grails Web Service Front End No True Domains

I have an existing application that is a front end application which retrieves all of its information from external Web Services. I want to re-create this application using the Grails framework, however the use case is a bit odd. Grails is Model driven. In this case I really have no Database tables. My data is received real time through a web service call. My question to the community is how would you go about implementing the following use case:
Employee Search:
All employee data will come from a web service call. I need to allow the user to enter for example an "EmployeeID" and select a "Customer".
The Grails application then makes a web service query to the appropriate web service and pulls back the results.
HERE IS THE UNKOWN PART: What is the best way to take these results and fit them into the Grails model? In other words, I need to display a Data Grid of the results (Search Results). The grid should work like the Grails list action, allowing the user to sort on particular columns, pagination etc.
I would have to think that this use case is a common? What is the best way to lay a project like this down? Should I use external javaScript libraries like Dojo or JQuery to provide the grid functionality?
Performance is also a concern to an approach
There is no one single way to create Grails applications. Often applications do make use of domain classes that provide easy access to data in relational database tables, but you can easily switch to a NoSQL datastore or even use no direct persistence like in your application.
The simple answer to your question is that you should just create non-persistent data classes in src/groovy and src/java that represent the data you're working with from your web service calls. You can still use Grails for its controllers and GSPs, taglibs, services (non-transactional of course since there won't be database access), and also take advantage of the many available plugins.
You shouldn't have to do much to use the standard generated controllers and GSPs to display data with sorting and pagination. The generation scripts do expect domain classes, but you can cheat a bit to get those generated (and of course you can always code stuff by hand). For example if you have a Person class in src/groovy/com/yourcompany, move it to grails-app/domain:
package com.yourcompany
class Person {
String firstName
String lastName
}
Then run grails generate-all com.yourcompany.Person and it will create the controller and its unit test, and the GSPs. Now move it back to src/groovy and use it as you want. The GSPs don't expect domain classes, they just expect individual class instances or lists of instances.
You'll need to convert controller calls to stuff like person.save() to use your web services instead, but much of the code should be reusable.
One thing you can take advantage of is validation. You can annotate your classes with #Validateable and define constraints to take advantage of Grails validation for non-persistent classes - see the documentation for more details.

ASP.NET MVC and Listener/Event

I would like to improve my knowledge, because I notice several time, I am convince I develop without to use the right practices, exemple to export a csv in ASP.NET MVC, I create in the controler 4 private methods, these methods do the necessary and return data.
I combine in 1 method, the 4 methods and call the parent method when the use click on export CSV.
These 4 methods are used in two places differents. So I can factorize the code in one for each or maybe it's possible to use delegate. Sure.
So I follow the tutorial from
http://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx about the event
and
http://msdn.microsoft.com/en-us/library/aa288459(v=vs.71).aspx about the delegate
And now, I think, it's not possible to create a listener to manager event in Web context.
My assumption is Web is not connected env, so you lost context each time.
Do you know a technical way to manage event+listener with webContext?
If you have any documentation/link about a pattern to implement it will be a plleasure to read.
You can make your API (Controller action/ WEB API) ‘context/session aware’ by using a session Id to refer to the same session. This way your server side logic will be able to ‘remember’ things for you, thus emulating a concept of a context.
This approach falls out of favour when you look at it from scalabilities’ point of view where your request would be served by one of many servers in a server cluster (unless you implement a dedicated session sharing mechanisms).
Best would be to implement a business service layer which would encapsulate all you atomic and repetitive logic and get the controller actions / web apis to call the service methods
hope this helps

Why should I use WCF with MVC?

I'm testing ASP.NET MVC 3.
And for an ajax call, I can use a MVC controller Method, or a WCF service.
But why would I use WCF, if I can do it with MVC ?
My questions is : Should I Use WCF services with MVC, or not ? And Why ? And in which case ?
Thanks,
WCF is a framework used for developing web services. The idea of a web service is that it decouples functionality used for providing raw data from functionality used for treating the data and providing it to the end-user. There are a few advantages to this:
If you are providing an API, you don't know how the data will be used. You want to simply provide raw data to a set of applications and let those applications handle the rest. A web service does just that... it opens up the data layer of an application while leaving the rest closed.
It can improve data-layer maintenability by enforcing loose coupling. Loose coupling means that the components of your application are not entwined with one another. This is a good thing because it makes it easier to make modifications to parts of your application without disrupting the rest. For example, if it is understood that a given function call will return a set JSON object, you can make changes to the table structure of the database that provides data for that object without interfering with the code of the consuming application. This works so long as you uphold the predefined data contract by always supplying the same type of data in the same format. On the other hand, if database queries, connection strings and the like are all hardcoded into your application it makes modifying your database logic significantly more difficult.
In your case, if you are just developing a small to medium-sized web application and have no intention of launching an API or similar service, there is probably no need for WCF.
Keep in mind however that while you probably don't need to write a WCF service for your application, you should still try to loosely-couple your application layers as you would with a service. You can do this by splitting data-access code or object (entity) definition code out into separate projecs. Loose coupling, whether it is implemented with WCF or just MVC makes maintaining your project simpler, easier and more affordable and is overall a very good practice to abide by.
MVC is fine, you really don't need WCF for this. MVC creates some sort of REST API (all your action methods get their own URL that you can use to call the method), so you can use that.

When should I consider implementing a Service in Grails?

I'm new to Grails and web development. I started doing a project on Schedule management website stuff. I came across the Service concept that is provided by Grails. I understood the concept, but still I have confusion on when to use services.
For example, I need to implement a search module, where the manager can search for a user to find his schedules. In this case it will be good to implement it as a controller or as a service?
So,
When and where should I use Service?
To add to Grooveek's answer;
It is also nice to use Services to keep your Controllers nice and clean.
So Views just render data to the screen, Domain objects store state, Controllers route the user around the application, and Services perform the work.
I don't have enough reputation to comment on an answer or vote up so I have to provide an answer that really should be a comment. Anyways...
+1 on #tim_yates answer. Gotta love thin controllers. 2 things that I would add to the description of a controller:
Would be to translate parameters from the browser before hitting a service (e.g. Date, number, etc.)
Would be to translate data returned from services into something consumable for the views.
For me, ideally, services would never deal with translating a String parameter to it's inherent type. Or deal with building a model to be displayed on a view.
What and where I should use Service?
When you want your controller do to something that may be reused by other controllers
In our application we're doing a functional separation of service. We have a CorePersistanceService, which provides method to create, delete, update and manipulate Core Domain Classes (core for us).
I think persistance services are a good way to reuse GORM code throughout Grails code. You can create method in domain classes, but I don't like that, it's way less maintanable I think
We have a PDFService class for our PDF creation, a SolrService which connect to Solr, a Statisticservice that gather all our methods which collects statictics on our datas
Services in Grails are a manner to gather methods around a particular functional theme, in order to give possibility to reuse them in controllers (I forgot to mention our SecurityService, which is a pretty good Cross-Applications Example)

Resources