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.
Related
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 ?
I'm building a web application using ASP.NET MVC6 that needs to be accessible via a web browser (via Views), as well as from mobile applications via Web API. The thing is that I would like to avoid duplicating business logic in controllers.
I know that MVC6 controllers return an IActionResult. When used as an MVC controller, the IActionResult might be a view. When used as a Web API controller, the IActionResult might be data (such as a list of products). The same controller might have actions (two different actions) that return both views and data.
But my requirement is to have one single method which can be used to render views when called in normal way in form of website and return data when called as Web API method.
As you’re already aware, MVC Controllers and Web API Controllers are now exactly the same. They’ve been unified as of MVC 6.0.
When you say you’d like to avoid duplicate business logic in the Controllers, may I ask why is it like that in the first place?
Do you have/shouldn’t you have some sort of Class Library project acting as your Business Layer in which you store all your relevant business rules?
For example:
Contoso.Web ( MVC 6.0 application)
Contoso.Service (Class Library holding your business rules)
Contoso.Data (Class Library holding your DataContext and Entity
Framework stuff...)
Contoso.Core or Contoso.Domain (Class Library holding your domain
classes/POCOs)
In addition, you want the ability for your application to be viewed from within classic browser as much as from mobile devices. Have you considered building a SPA (Single Page Application) which gets you best of both worlds?
The SPA approach, will allow you to create Views and using a client side framework (ex: Angular) will allow you to invoke your WebAPI which in turn would invoke your Contoso.Service layer.
Unless, of course, your mobile app is a native one that only needs to invoke your WebAPI
If there is a way for an IActionResult to either return a View or some Data, the concern I have is that this IActionResult may start growing and having some discoverable logic in them which may be hard to maintain/debug in the long run.
You also increase the likelihood of regression when you modify its behavior since you’ll need to test both the Views and the mobile app.
With little I know about your project, I’d take a look at SPA approach to see if it fits your need(s).
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 ...
can any one explain the difference between the mvc and web application in asp.net.
in mvc we can find controllers folder. cant we able to find controllers folder in web application..! please vanish my confusion.
MVC uses controllers to orchestrate the models and views to provide user interfaces to the user.
Web forms doesn't use controllers to achieve this, it uses code behind with events.
MVC is built around the notion of separation of concerns - each thing is responsible for its own bit, and shouldn't be concerned with what other bits are doing. Webforms has them a bit more mushed together, where code sits associated 1:1 with the webform (in the code behind), often leading to business logic creeping into the UI.
WebForms uses a powerful eventing system to help abstract away some of the complexities of HTTP, such as its stateless nature. MVC doesn't do this, which requires the developer to work within the confines of a pure HTTP environment. The eventing system in WebForms lets you quickly wire up events in a familiar way if you've come from a VB6/WinForms background (which the target audience had when ASP.NET was first released).
Have a look at http://www.asp.net/mvc which has a lot of great tutorials on getting started with MVC.
An ASP.NET MVC application is an application which depends upon the ASP.NET MVC Framework. MVC stands for Model, View Controller, the three components which define an application created using the MVC pattern.
The MVC pattern aims to seperate an applications logic, data and presentation into distinct, somewhat independent components.
Model
Models are a representation of an application's data. For example a shopping application might have a Cart model to represent the state of a user's shopping cart.
View
A view is a visual representation of the data contained in the model. A view class should knoow the specifics of how the model(s) it uses should be presented.
Controller
The Controller's job is to handle user input and update the state of the Model to reflect the changes that were made as a result of user action. For example imagine the user is viewing a Contact Us page and clicks the Submit button. The controller would respond to the button click by updating the model with values from the form fields and then save the model, causing it to be validated and then written to the database.
This is a very shallow and incomplete explaination of the MVC pattern you should head over to the ASP.NET MVC homepage to get a more complete view of the MVC pattern and the ASP.NET MVC framework.
An ASP.NET Web Application uses a separate framework known as Web Forms. Because Web Forms does not use the conventions defined in the MVC pattern, the Web Application template does not create a similar folder structure .
The use of either framework is not mutually exclusive, the two represent differing approaches to the same problem. With respect to which is most efficient for data access I would refere you to Michael Shimmins' excellent comment
What is the best method/technology to sharing the same data access layer between WPF, Silverlight, and ASP.NET?
I am using ADO.NET Entity framework, and was thinking of a creating a DAL using the Repository pattern.Then using the RIA Services as a dummy middle man to connect Silverlight and ASP.NET. Is this a solid plan or are there other better solutions out there?
One of the solutions I like to use is the following :
- Have a project storing only the entities (for example : Player, Game, Entity) with no reference to the database at all.
- Have a project implementing the repository pattern (Repository, Repository etc...)
- Use ADO.NET Entity Framework code first approach to map with the database (it creates a dynamic child object of your entities contain in your project, see ScottGu's blog for an explanation on how to use it)
Connecting Silverlight to your pattern can be done with Ria Services or classic WCF services. Usually I try to use WCF whenever possible as Ria Services is not really compliant with an MVVM development.
If you want to use WCF and share your DAL entities with Silverlight you can create a MyDal.Silverlight Silverlight class library project and add symbolic link instead of copies of every entities you will want to share with Silverlight. Then when you'll add a service reference with visual studio it will be smart enough to not create copies off Player, Game and User to you Silverlight project.
If you want to use Ria Services it will create copies of you entities anyway.
Hope that helps
John
RIA Services
RIA services will certainly take the burden off you for all the WCF plumbing. It has a few minor flaws (lack of certain data types), but there are workarounds for most problems.
The validation model (using attribute decoration and custom validators) is very strong and a great place to hang business rules.
RIA coexists happily with ASP.Net, so that is another plus. Behind the scenes it is just another WCF service. We are happily using RIA services with MVVM and Prism.
ADO.Net EF model
This is a tried and tested feature rich model. The only problems I have found related to many-to-many relationships. Again there are workarounds.
DAL
As RIA change sets are managed for you on anything, including POCO, this is the area that will need the most attention. It is considered "bad" to expose your EF model directly to RIA and that will certainly not insulate you from data changes.
I can't specifically recommend any one pattern yet (still experimenting), but make sure your choice is compatible with IQueryable. The paging feature and appending to Linq queries for server-side execution are features you do not want to lose!