I’m aware that not everyone uses a thorough architecture when developing an MVC application but let’s assume I have the following architecture:
App.Core --> Class Library (POCO or Domain objects)
App.Data --> Class Library (Repository and Entity Framework)
App.Service --> Class Library (Service layer with all business logic)
App.Web --> asp.net MVC 3.0 project
App.Data --> Has a reference to App.Core
App.Service --> Has a reference to App.Core and App.Data
App.Web --> Has a reference to App.Core and App.Service
Inside our MVC application we try to follows this approach:
Inside our Controller (within a method), we instantiate a ViewModel.
We fill that ViewModel calling methods from our App.Service Layer
Once the ViewModel is filled, we return it to the View (so the view
is now strongly typed).
This occurs 99.9% of the time. It is clean, we like it and it leverages itself pretty well..etc!
Now my question is the following:
If we decide to move our application to MVC 4.0 and start using the
new Web API approach, I’m not sure I fully understand where (or how)
it would fit in our current architecture?
Keep in mind, that we are open to change this around!
Should we create a new App.WebAPI layer that sits between the App.Service and App.Web?
This means inside our Controllers, we would no longer need to call the App.Service directly but instead the new App.WebAPI layer?
Or, leave the Web API inside the App.Web layer and make the Controllers call the other APIControllers which in turn would call the App.Service layer?
Not sure if I make any sense here…but please feel free to suggest anything as I’m curious on different inputs.
Thanks
There are a couple of cases to consider:
Do you want to make this Web API serve as service layer and data access for your MVC application? If, yes, then you should completely remove all references of App.Service from the ASP.NET MVC project and have it query the Web API instead to fetch the data. In this case the Web API sits between your ASP.NET MVC application and the data access. It is the Web API that talks to the service layer and exposes it over the HTTP protocol.
Or do you want to provide an additional API for your web site that can be used by other clients (other than web browsers)? In this case the ASP.NET MVC application and the Web API sit on the same layer. Both query your Service layer to fill view models, it's just that in the case of the MVC application you are passing those view models to views which in turn convert them to HTML whereas in the Web API layer you probably use slightly different view models but which are still populated from your service layer and are passed to the client used the corresponding serialization mechanism (JSON, XML, ...)
I know this is late but I was actually looking for the same advice and I found this post.
Wouldn't having "both the MVC and Web API sit within the same layer" mean more maintenance work on the code, or maybe duplication of code? isn't the mvc web considered as a browser client? .. to me it makes sense to have the WebAPI your only layer to everyone else and in turn it would call your service layer for processing.
What is the benefit of leaving both the Web API and the MVC talking directly to the service layer? Can't the web API be the wrapper around the service layer?
Related
There is a sales service implemented as a Telegram bot. I need to create a website control panel for this service. Since the service is a .NET application I am thinking to use ASP.NET Core technology.
How do I transfer data from the controller action to the Program class containing all the functionality of the service (maybe it is worth defining the Program as a static class)?
You may have misunderstood Asp.Net Core. .net core adopts the pipeline mode, that is, when you call the action in the controller, it will enter the middleware pipeline of Program.cs(.net 5 is Startup.cs), and execute in sequence according to the order of your middleware, adopting the principle of first in, last out. This means that if you follow the normal .net core logic, the value you get in the controller (except the parameters defined in the URL), you cannot pass it into Program.cs. When you successfully enter the action of the controller, Program.cs has been executed.
Not sure what your sales service looks like, but I think you can register it as a service and use it in your controllers using dependency injection.
Helpful link: ASP.NET Core Middleware.
My team maintains a very large .Net Core 2.1 web site. Lots of controllers, lots of services that get injected into the controllers via constructor injection.
Sometimes due to developer error a service class is no longer added to the DI container during startup. Obviously this leads to an exception when MVC tries to construct a controller that relies on that service (in response to an incoming request).
Problem is that this may affect only some lightly used controller, so our (far from perfect) regression testing doesn't pick up the regression bug. But it is still bound to be picked up by one of our (very demanding) customers.
I though of writing a unit test that would
Instantiate a ServiceCollection class (that implements IServiceCollection);
Call our own method that adds all services to that service collection (the same method used during normal startup);
Find all controllers through reflection, and try to construct them the same way MVC does - by getting dependent services from the DI container.
So my question is:
Does this approach make sense?
Is there an example somewhere that I could use?
Failing an example, how would I achieve 1) and 3) ?
I have started working on an application which is structured as follows:
UI - ASP.Net MVC web application
Service Layer - WCF
Entities - a simple class library (exposed by WCF layer)
Data Layer - for database interactions.
Till now, I was defining my models in Models folder of my web application, but now as we have decided to expose them by WCF service (as this application will be consumed by other applications as well), I need some help here.
I tried putting all my model definitions in Entity layer which is exposed by WCF service decorating them with data annotations as well as DataContract attributes. Now, I am able to reference these entities to bind them with my views. But, data annotation validations are not working for me.
Can anybody please help me for a workaround for this ? I have been searching through web for solution but almost all tell me to put a reference of entity layer in web application which will be tight coupling that we do not want. and the other option is to redefine all entities with data annotations in models folder of my web application,which will be duplicate kind of coding.
Is there any better approach for this? Any help appreciated.
Update:
To consume WCF entities, I have put a service reference in my web application. Now, just to check I modified that Reference.cs file by decorating my data Member explicitly with [Required] attribute and it is working fine. but, I understand these changes will go away whenever service code is generated.
Is there any way I can bring that Data annotation attribute here? Kindly help.
As for me It's bad idea, DTO for transfer, Model for MVC.
Look like similar problem
Why You Shouldn’t Expose Your Entities Through Your Services
DTO’s Should Transfer Data, Not Entities
I have business layer and UI layer in separate projects within a same solution. What i need is ,connect this UI with business layer which coded in c#. UI created using MVC3 Razor.
What i should use as model in MVC application? am i need to create Service reference to business layer to generate some proxy?
then can i use those proxy as a model? please help me..
if you can provide me some tutorials
i tried this but no more idea with MVC :
http://www.dotnetfunda.com/articles/article816-understanding-the-basics-of-wcf-service-.aspx
Unless your project (or architect) demands that all methods of your app access a services layer, I would try and avoid using WCF unnecessarily (think of it - it means that all of your data between web server and back end goes over the wire, which has implications such as performance, serialization of data, and also potentially limits the lifespan of database connections and transactions, which can deprive such as lazy loading).
If you concur, the suggestion would be to ensure all accessible interfaces in your business layer are exposed on an interface, and then consume or inject the BLL interface directly into your controller.
You need to be careful about the word "Model" in MVC - ASP NET MVC encourages ViewModels, which are specific to the presentation tier and passed between Views and Controllers, as opposed to "Entities" which represent the more logical domain model as used by business logic and which can be tied to data persistence using an ORM such as EF or NHibernate. The MVC project template lumps everything which isn't View or Controller into "Model" which isn't necessary very helpful.
However, if you do choose to access your BLL via a WCF Services layer you still have some design decisions to make:
Choose whether you share the back end entities on the client side, or do you instead use proxied entities.
Choose whether you consume / inject the WCF service proxies directly in your controller, or do you create another facade layer (e.g. CAB calls these ServiceAgents). The latter would make sense if there are separate teams or vendors building the SOA side vs the Client side in order to accomodate changes to interfaces.
I am new to WCF but have been working on asmx services for a while.
We have an effort underway where we want to introduce a service layer between our UI/aspx pages and Database Layer. Most of the business logic exists in codebehind. So the current setup is UI/aspx->DAL->Database. We want to do UI/aspx.vb->WCF->Business Layer->DAL->Database i.e by moving everything from codebehind in WCF...Is this a good approach?
Our future goal is to get the flexbility in replacing business layer, so there is no dependency between UI and business layer or database.
Need some guidance on how we can use WCF in right way to do layered architecture approach..
Your help is much appreciated.
Thanks.
In principle service layers are a good idea but if you're simply introducing one for the sake of it then it's a lot of effort for no return.
The main benefit you will get from a service layer is that you will have a lot more flexibility in the type of clients you can connect to it. At the moment it's likely that the only application that can use your DAL is your ASP.Net app by adding a service layer and exposing it using WCF end points you'll have the option of connecting other SOAP or REST clients which is a good thing for future enhancement.
However if you're only ever planning on using your DAL with your existing ASP.Net app then there's no guarantee that you will gain anything and in fact could make your life harder by adding a service layer. If you do all your data retrieval server-side, i.e. don't use AJAX, then a service layer would be pretty pointless.