I am using the ASP.Net BoilerPlate, a starting point for new modern web applications using best practices and popular tools. I am making an MVC, Web API, single page web application.
But I have noticed that based on the documentation that the Nlayer is based like bellow: where you can see it better on the link (https://aspnetboilerplate.com/Pages/Documents/NLayer-Architecture)
What is strange for me is that the management of DTOs and DTO mappings are made on the Application layer, I tough it would be made on the Web Layer on the ASP.Net MVC Controller or on the Web API Controllers, that would call the Application Layer and from the Controller it would make the mapping of DTOs.
But it seems that the MVC Controllers are not even used according to it's example linked on the documentation (https://www.codeproject.com/Articles/1043326/A-Multi-Tenant-SaaS-Application-With-ASP-NET-MVC-A).
If I make the DTO mapping in the Controller and make the controller Application layer responsable only to call the Service and retrieve Entities is not a better practice ?
Related
Cenario
Website: ASP.Net MVC 5 managing models, controllers and views.
Api: RESTful Web api managing models, controllers and returning JSON
The problem: Code duplication in BL. We are always redoing the same logic in both places.
The approach I have in mind:
Take the BL out of the Website MVC and keep it only in Web Api in a separated VS solution
The Website now is a consumer of Web Api
About the content negotiation, I think in two options:
Web Api "knows" which format to return (ViewResult, JSON or XML) and serialize/deserialize in BL depending of who is requesting (website, mobile apps, etc.). The advantage I see is to keep taking
advantage of strongly typed model to render a view in Website
Web Api always return JSON and the consumer app handle result in client
Questions:
Is this approach a good practise?
Which is better: Web Api always returning JSON or a smart Web Api who "knows" which format to return?
Like #David said, you don't really need to consume web services in your MVC controllers. You could just design it in such a way that your MVC and API layers are just another "view" to your Business layer. So, in case you are thinking in a terms of your visual studio solution, your might have a Data layer project, a Business layer project and 2 front end projects MVC and API.
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 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 ...
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.
I have an existing Asp.Net MVC Website and I would also like to provide a Web Service from the same domain.
What is the best way to approach creating a web service in this scenerio?
Do I add to this project or...?
You should be able to add an WebService file directly to the MVC project.
Right click on solution and select add new item, then select the web category and att the bottom of the list there should be Web Service.
Just remember to check that the routes does not eat up the call to the webservice.
That way the webservice can get access to the same model classes as the MVC application.
You can add a web service to the project just as you do in regular ASP.NET web apps, however, MVC basically IS a web service. You could create a controller that handles all the requests that you want your web service to handle.
With the advent of MVC it is quite common to do applications that only ever load a view once, then use AJAX and client scripting almost the entire rest of the life of the application. Your AJAX calls just hit up action methods for their goods and then use the deliciousness that is JSON to parse the data and utilize it.
In my opinion designing a web service as a controller instead of using [WebMethods] is far simpler and a lot more fun!
First, the question is "what do we mean by web service?" This can mean anything from a MVC page that responds using XML, JSON or some other agreed upon format to full blown SOAP and WS-* encumbered nightmares.
Anyhow, perhaps the best place to start is the WCF restful services -- these play very nicely with MVC, including routing.
The cool kids are using openrasta.