I wanted to get some peoples opinions on adding a web serivce layer. At my work, we want to start using web services to handle some of our operations.
Our current project structure that we follow for our ASP.NET MVC apps:
MVC App (View/Controller/ViewModel/Service Layer) --> BAL (Business Access Layer) --> DAL (Data Access Layer)
The MVC app, BAL, and DAL are separate assemblies.
There is a Domain (model) assembly as well that is shared among the MVC/BAL/DAL layers.
The plan is to create a web service that will handle all security functions. This web service will be used by multiple web applications. When we make changes to the Security Web service we only want to modify code in one place and not every web app. So I'd prefer if the MVC project has nothing in it that is tied to a web service.
So I was thinking of adding a Web Service Layer between the BAL and DAL layers.
So something like this:
MVC project (View/Controller/View Model/Service Layer)
calls
BAL Layer (Handles caching / DB Transactions)
calls
Web Service Layer
calls
DAL Layer
What are your opinions?
A couple thoughts.
You are putting your web service layer between you BAL and DAL. This means everything will need to go through your web service, including functions which aren't related to security. I think this is adding an additional layer of complexity. If multiple websites are using the web service, create it as a stand along application/service. Then you can call the service from the different layers of your application depending on what layer needs the service. Generally you would create a Webservice wrapper with a clean interface so you can easily call the Web Service from your any layer in your application.
For the sake of discussion, lets say your web service handled validation of login and password of a user. You can connect to your webservice wrapper directly in your MVC project to see if the user data is valid, then you can log them in if it is. Later, if the user performs a function, and the business layer needs to check if the user has permissions, that layer can use the api wrapper which calls the api to see if user has permissions, and so on.
MVC APP
/ \
BAL --> Web Service Wrapper
/ \
DAL WCF WEB SERVICE
As someone who supports an application that is ridiculously layered as so.
GUI
BAL
DAL to WebService
Webservice
WebBAL
WebDAL
I would suggest putting your GUI as close to your webservice as possible.
Related
I need a suggestion: I currently have an ASP.NET web forms application (pretty large scale) with three tier architecture and ado.net for database communication.
Application structure is
Web > BLL > DAL > BO,
BLL for business logic and DAL for database interaction using ado.net (stored procedures).
There are other 4 apps connecting with BLL that make applications tightly coupled. Now I have to redesign one application so we decided to change underlying technology.
And I currently have few options:
Change front end layer and rewrite complete app to Angular and have API layer on BLL (most time consuming and complex solution I guess)
Change font end to ASP.NET MVC and directly call BLL from controller (we can reuse existing html mostly, but app will remain tightly couple and still monolithic)
Change front end to ASP.NET MVC and write API layer on BLL and connect controller to BLL via API (not a good idea to add an extra http request for every sever call client > controller (server) > API ( server).
Please suggest any alternative approach. Is this good option to rewrite complete complex application from ASP.NET MVC to Angular?
I would suggest using ASPT.NET CORE WebAPP and one or more ASP.NET CORE Web API, REST, microservices, so you don´t need to expose your services on the web and would be better to maintain it and for huge systems. Used of EF core, with CQRS pattern, is a very good choice within your WEB API so you can implement your BLL on it. Try to use to SOLID principles, mostly the D, dependency of inversion, that has already a built in IOC container so you apply the dependency of injection on it. Don´t forget to secure the system with authorization and authentication. OAuth 2 is a good way to go!
I am launching my startup and i need to make a critical architecture choice.
I will provide a SAAS web application for my clients, they have different specific needs but the main purpose of the program is the same, automatically generating documents and pdf.
Technincally i choose ASP.NET MVC, WebAPI, EF Code First. Now I have a working proof of concept with only one project (1 db, 1 asp.net mvc client, 1 asp.net webapi, 1service layer + 1 repository)
I will have one database for every client (easier to maintain, scale ...)
One WebFront for each client with personalized html/css templates and of course specific data/menu
Only one WebApi service exposing all services for each client,
For example /api/client1/, /api/client2/ with almost the same api calls but not the same data returned.
For each client a service layer (Class library dll) that stores business logic, data acess, POCO/DTO.
Each Webfront shares reference to specific service DTO/POCO.
I need of course my solution to scale horizontally, not vertically.
So is it a good choice?
Do you have any recommendation/better solution ?
Can I put All this in the same visual project ?
I really would like to have the service layer(business) in only one project, and with good Object Oriented approach I can serve all my clients with common needs shared between all of them and specific one in derived objects.
Thanks for help
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I have three core applications that have their own business functions (networks, active directory and helpdesk). Each are running ASP.NET v2 or v3 and have their own respective databases. However, the application functions have merged a bit so models were recreated in each application and app logic along with it. So now I have some difficult to maintain code. So here is my question:
Is porting my models and repositories over to WCF a reasonable choice for this type of architecture?
Is using a service stack such as serialized json calls a better choice? I'd imagine this would be faster than setting up a central wcf app.
I'm not too familiar with communication between asp.net mvc web apps so please point me in the right direction.
I would recommend developing a service layer per the design pattern described by Fowler. This service layer encapsulates the various domain models and repositories and handles interactions between different domains/models. This will be an assembly and not a WCF or any other type of web service. If you require a WCF web service then it will be a very thin layer which basically has a contract that mimics the service layer and only purpose is to provide a web service interface or API.
There are a couple of ways an MVC application can interact with your service layer. If you are creating view models in your Controllers then it can access the service layer assembly directly. There is added overhead to calling it through a web service that is most likely not necessary in this case. Using this approach the service layer is pretty much your Model in the MVC trio.
The other way to access the service layer is from the Views/client using AJAX for rich clients. In this case you would use MVC to put a REST API on top of your service layer so that you can make AJAX POST's, using something like JQuery, directly to the web service to update and retrieve data for the web page.
Note with this architecture you can use a combination of both approaches. You may access the service layer directly from the Controller to render some initial pages and then use the web service REST interface for AJAX calls during user interaction.
I want to send an email confirmation from my service layer (class library). This can be triggered from an asp.net mvc controller or a wcf service.
How do I build the Url from the service layer?
The service layer shouldn't have knowledge of how urls are constructed in your web application, especially because those rules can easily change. Also this makes your service layer tightly coupled to the web layer and less reusable. What if tomorrow you wanted to reuse this service layer in a desktop application?
IMHO that's an information that should be passed from the controller to the service layer.