I have been trying to get to grips with the use of ASP. NET WebApi recently, I’ve watched a bunch of tutorials and read quite a bit material, but not finding the information I need. This maybe a very basic question, but my idea is to host my webapi with IIS and was aiming for a 3 tier Architecture, something like, Presentation Tier , Business Log and Data Access.
Now I create an MVC 4 project for my presentation tier. But what I am not understanding very well is do I then create another MVC 4 project with a web api template for my business logic and strip out all the controllers, views etc?
Hope I’m making sense.
Thanks for reading.
Whether you should host the WebAPI in a separate ASP.NET application than your MVC project is debatable. Both approaches are correct. For example if you don't want to expose the WebAPI to the public you could host it in some internal network that is accessible only by your MVC application. If you want to expose it to the public then you could host it alongside with your MVC application. So it would really depend whether you want to expose an HTTP API to the public or not.
3 tier architecture doesn't mean (in the general case) SOA (Service Oriented Architecture). If you really need SOA - it's better to have separate projects for API project (Service) and Web UI (Presentation). But if you just need SOA and you don't need REST services (for public access) then it maybe will better to use WCF instead of WebAPI.
Marcel, your MVC is pattern in order to define your presentation tiers, you can also use WebForms, but you have selected MVC,
You must also create Business Layer and DataAccess Layer. these tiers are independent of MVC.
Select MVC just permit you to facilitate unit test (Controller) , facilitate future changing on view's technology, separate businness logic from presentation ...
Related
I want to migrate my WCF services to Web API / MVC6.
Currently I have one application hosting multiple WCF web services (http://{ip}/{app}/Service{x}.svc/{vs_endpoint}). This model is pretty good, we can separate the public services from internal services and we have control over each service in particular, although they all are under one single application.
Would I be able to achieve similar thing in Web API / MVC6, having one project for multiple services? From my initial investigations I understood I would need to do something along these lines.
If yes, it would be nice to have some recommendations how to structure this project.
Also, can you share some pros and cons about one vs multiple projects to host these services?
Thank you in advance!
Yes you can achieve this by using either separate controllers or logically grouping controllers into areas.
Once you start programming you will automatically came to know that how it is possible and easier to do than wcf.
good luck...
I have an application which is built in ASP.Net WebForms and Silverlight.
There is another WCF services application which is accessed by silverlight part of my application.
Now I have to Re create the whole application in an MVC Single Page Application(SPA) and of course the WCF one because now I would need Web API for that.
An initial solution comes into mind is to add a web api project into wcf services application and start creating web methods there and call wcf methods from there if that functionality was already there.
And for webform start a new spa with mvc project from scratch and use durandal or any other spa client framework(hell of coding).
Any useful solution/advise? as I am looking for simplicity.
I searched around and found some questions but really did not helped as they are about merging with existing apps.
Note: application is a large application with a lot of functionalities
You have to decide how confident your team is with client side frameworks. Development of Single page applications may not be easy in the beginning, but you will get used to it very quickly. It's very important to give your team the right training.
In my opinion, Durandal is the simpliest, most elegant and complete framework to build enterprise level SPAs. It is important to know how knockout, requre and durandal's router and composition work. For data centric application I would use breezejs to manipulate and cache data on the client side and request it from the server side. Breeze works best with Entity Framework on the server side, but it's not necessary. If you can use Entity Framework, it will simplify your development, because it can generate metadata of your database structure for breeze. If Entity Framework is not an option, metadata can be written by hand.
I would make server side as thin as possible. Serving data from your database using web api with ORM of your choice and some cshtml pages.
Durandal Get Started is a good place to start.
Durandal Auth is a very good template for enterprise level SPA. It may not suit you completely, but you can use it as a guidance to build different modules of your application.
Breeze samples I suggest you consider using breeze. There are good courses available on pluralsight.
Knockoutjs has good training on data-binding.
I'm working on building an application that's based on SOA. I have bunch of business services that I should make them available as components to another applications (so I'll use web services -SOAP-).
The application presentation layer is MVC.
1- Model: Contains DataBase methods (ORM is used).
2- Controller: Contains calls to the model methods as well as methods to handle simple view actions.
3- View: Contains rendering content only.
So, can you give me a simple scenario how can I combine web service with my MVC application, my suggestion is to separate the model as web services, is that right?
I'd tackle it this way: (YMMV)
Build a data tier assembly housing all your data access. Call it the DAL. It will contain all data access methods. This will enable re-use, but also allow for methods used by one application below. This is where your EF model can live.
Build 2 web projects: MVC and web services. Each will implement business logic to satisfy their respective requirements. They'd reference and call into the DAL as needed for data access. As you noted, they're both presentation-tier services. One has a user interface, the other is a communication endpoint for remote web service consumers.
Deploy both onto an application server as needed. Suggest creating 2 applications/sites in IIS - (i.e. "Web" and "WebServices"). This separation of applications ensures that one can be changed/downtimed/versioned without effecting the other.
The MVC project/app will still have its Models, Views and Controllers as per normal. The biggest change here is that the Models would be used only for ViewModels as needed. It would contain any business logic to satisfy the UI requirements. Its controller methods would call the appropriate DAL public methods as needed.
The web services project/app would be able to be changed independently as needed, while the data access would remain.
1) Place all your service operations behind an interface.
2) Consider using an Inversion of Control container to utilize dependency injection in your application. This allows you to mock your dependencies and unit test your controller logic more easily. Some examples are Windsor, Ninject, StructureMap.
3) Consider using strongly type view models for your views, instead of the objects that your ORM works with. You'll want to set up some mapping classes to help manage this, but a lot of the pain can be taken away by using something like AutoMapper.
Here's some good links on the subject:
How we do MVC – View models
ASP.NET MVC View Model Patterns
Never use web services for the sake of using web services: You should first have a problem that needs solving, and see that web services are the best solution to your problem. So depending on your need, web services can be used in a variety of different ways.
For example, since you say MVC is your presentation layer, you may want to insert web services as a layer between the Model and the Controller. Rather than invoking your model (data layer) directly, the Controller invokes your web services and provides a web-based front-end to the services that would otherwise be available via your SOAP API.
Another option is to make both your MVC front-end and the SOAP services access a common business/data logic layer, each providing their own "API" for the same back-end.
But again I emphasize: web services should not be used as solution in search of a problem. If it's not obvious to you where the web services should fit into your architecture, you are very likely better off without them.
For clarity when I mention tiers in my question, I am referring to physical tiers (i.e. different servers for presentation, application and database)
My company has a public facing website that is currently built as a typical 2 tier system (web server and database server).
Soon a project will start in which we will be re-writing the whole site. We are required to split the project across 3 physical tiers. Actually, when you consider the browser then you could consider it 4 physical tiers.
In my experience most asp.net applications are built on 2 tiers. The web application itself may have several layers but physically it is deployed to two servers (web and DB).
I have searched for examples but it seems that layers and tiers get confused. I see a lot of multi-layer examples but no multi-tier examples.
In a nutshell it would seem that the web application makes web service or WCF calls to the application layer that marshals data to and from the database using ADO (or L2S or EF).
Does ASP.MVC help achieve this? Does it make it any easier or just different?
Is there a good reference or example of this somewhere?
I don't think adding another tier increases security, but it definitely slows down performance and significantly increases development cost and complexity.
In the end, you can partition your application with an additional tier anyway you want. If it were me, I'd probably create the dumbest pass through tier I could if I was given this "interesting" requirement.
In fact, managing security around another tier implies significantly increased opportunities for security holes to be accidently exposed.
ASP.NET MVC should have no impact, but you will likely end up using something like WCF. For marshalling data back and forth, you probably want to use DTOs which are not tied to any particular database or ORM.
This is not a situation I'd be happy to find myself in. Increased complexity does not lead to increased security.
Gday Rick,
I work for a company that has the same multi tiered policy due to security.
I have an ASP.NET MVC web application on one tier that connects to a application tier that a web service sits on and is basically a facade for the database and a mainframe. Pretty much exactly the same as your setup.
ASP.NET MVC makes it really nice and easy to use this setup because you can easily build a validated object model in your ASP.NET MVC application. Once the object passes all top end validation you can easily transfer it on to the application tier via a web service.
I suppose this would be easy to do with a classic ASP.NET application however I think MVC makes things a lot easier!
Check out my blog for an example of how I have validated my models before sending to the application server.
Cheers,
Michael
In my opinion ASP.NET MVC isn't going to help, or hinder this scenario. Basically you'd going to have your model exposed not as Linq2Sql, the Entity Framework or any other ORM but from the middle tier, probably by WCF.
This presents the usual challenge around authentication and authorization - namely how does authentication flow between tiers., but that's are unique to MVC, a WebForms solution would have the same sticking points You'll also lose the model validation bits that an ORM may supply and will have to provide that yourself in your web services repository, but that's just a matter of implementing the right interfaces.
This is an odd requirement. Did it come from the customer? It is possible that some customer education is needed.
I know J2EE systems can be split over three tiers, with web server on the first application server in the middle and a DB on the back end but I havn't heard of this with .NET.
As mentioned before... MVC won't really matter in this situation. The closes analogue I have is we had a financial client separate out their web services into tiers...
so something like
1) public facing load balanced web services
2) web services
3) application code
4) database code
I don't remember if layer 3 and 2 were physically separated (been a while) but essentially layer one was fairly thin and just threw the requests over the dmz to the inside service.
So you could probably do something similar with the web site... potential for bottlenecks, but would get you the physical separation you need.
Good Luck!
Does adding a Web Service to my ASP.NET MVC project break the whole concept of MVC?
That Web Service (WCF) depends on the Model layer from my MVC project to communicate with the back-end (so it looks to me like it needs to be part of the MVC solution).
Should I add this to the Controller or Model layer?
It sounds like you should split out your model into its own assembly and reference it from your MVC-application and WCF-application.
YourApp.Data -- Shared model and data access maybe
YourApp.Web -- If you want to share more across your web-apps
YourApp.Web.Mvc
YourApp.Web.WebService
If you want to do WebServices MVC-style maybe you should use MVC to build your own REST-application.
Is there a specific reason you need to add web services to your MVC application? Unless there is a specific reason you should use your controllers in a RESTful manner just as you would a RESTful web service.
Check out this post from Rob Connery for more information:
ASP.Net MVC: Using RESTful architecture
Separating the Model into it's own project is not breaking the "MVC" pattern. First off, it is just that -- a pattern. The intention of the MVC pattern is to clearly delineate between your data, the data handlers, and the presenters and the way you interface between them. The best way to do it is how Seb suggested:
YourApp.Data
YourApp.Web.Mvc
YourApp.Web.WebService
Something that might help you out is the MVC Storefront that Rob Conery put together. Go watch the video's here:
MVC Storefront Video Series
And if you want to look at the actual code in your browser to quickly see how he did it, go here:
MVC Storefront Codeplex Code Browser
I don't think separating the model into it's own assembly has any bearing on whether or not you're using MVC, you still have a model. Where it is is irrelevant surely?
I've had a go at doing this.
See my result at my blog
ps: I don't believe that this will break the MVC concept so long as you think that a web service is the model of a repository because all a web service does is returning a XML dump.
I have added web services to my application and it works well. I don't believe it violates MVC because it is an alternative interface to your model. MVC is not appropriate for web services because web services don't have a view.
Think of web services and databases as one in the same. Under this analogy, I think it makes sense to place your web service ingteractions where you place your database logic.