I've been using MVC for a long time and heard about the "Service" layer (for example in Java web project) and I've been wondering if that is a real architectural pattern given I can't find a lot of information about it.
The idea of MVCS is to have a Service layer between the controller and the model, to encapsulate all the business logic that could be in the controller. That way, the controllers are just there to forward and control the execution. And you can call a Service in many controllers (for example, a website and a webservice), without duplicating code.
The service layer can be interpreted a lot of ways, but it's usually where you have your core business processing logic, and sits below your MVC architecture, but above your data access architecture.
For example, you layer of a complete system may look like this:
View Layer: Your MVC framework & code of choice
Service Layer: Your Controller will call this layer's objects to get or update Models, or other requests.
Data Access Objects: These are abstractions that your service layer will call to get/update the data it needs. This layer will generally either call a Database or some other system (eg: LDAP server, web service, or NoSql-type DB)
The service layer would then be responsible for:
Retrieving and creating your 'Model' from various data sources (or data access objects).
Updating values across various repositories/resources.
Performing application-specific logic and manipulations, etc.
The Model you use in your MVC may or may not come from your services. You may want to take the results your service gives you and manipulate them into a model that's more specific to your medium (eg: a web page).
I had been thinking of this pattern myself without seeing any reference to this any where else and searched Google and found your Question here :)
Even today there is not much any body talking about or posting about the
View-Controller Service Pattern.
Thought to let you know other are thinking the same and the image above is how I view how it should be.
Currently I am using it in a project I am working on now.
I have it in Modules with each layers in the image above with in it's own self contained Module.
The Services layer is the "connector" "middleman" "server side Controller" in that what the "client" side Controller does for the client, the "Service" does for the server.
In other words the Client side "Controller" only "talks" with the "Service" aka Server Side Controller.
Controller ---> Requests and Receive from the <----- Service Layer
The Service layer fetches or give information to the layers on the server side that needs it.
By itself the Service does not do anything but connect the server layers with what they need.
Here is a code sample:
I have been using the MVCS pattern for years and I didn't know anyone else did as I couldn't find any solid info on the web. I started using it instinctively if you like and it's never let me down for Laravel projects. I'd say it's a very maintainable solution to mid sized projects, especially when working in an agile environment where business logic changes on the constant. Having that separation of concern is very handy.
Saying this, I found the service layer to be unnecessary for small projects or prototypes and what not. I've made the mistake of over complicating the project when making prototypes and it just ultimately means it takes longer to get your idea out. If you're serious about maintaining the project in the mid term then MVCS is a perfect solution IMO.
Related
There is a project that is built using JSF with Spring Integration.
See https://www.tutorialspoint.com/jsf/jsf_spring_integration.htm to get an idea.
JSP is used for the html templates. Managed beans (part of JSF) make use of Spring beans as a managed property, which in turn drive business logic. The goal is to rip apart this project and split it into a RESTful service and Angular front end.
What is the best way to do this without re-writing everything. Which components can I get rid of, and which components can be re-used? If I use Spring Boot for building the REST API, can I re-use the Spring beans?
Edit: I am new to most of these technologies.
Exposing your domain model through REST should be relatively straight forward using Spring/JPA, whatever. You should learn about DTOs and especially as it relates to problems about "Lazy Initialization" under Hibernate/JPA/Spring Data, etc.
Secondarily understand the concept of views into the domain model. E.g., shipping looks at the database differently than marketing. Same database, different "facades" or business layers with different set of DTOs.
Conceptually, reproducing a JSF front end in Angular is something that is both "the same thing" and "completely different" at the same time. The key difference, IMHO, will be the JavaScript concepts and paradigms underlying Angular/React/Vue or whatever you want to use on the Front End.
Consider that an AngularJS/React/Vue front end might be better off running on top of node.js in a separate container or server, and might have different databases that it accesses on its own such as loyalty points or currency conversion, etc. Don't be afraid to let the frontend folks "be" the application instead of the backend folks. On the backend, try not to lose information. For example, if a customer adds 3 items, then changes 1, then places the order, that's 3 separate pieces of information, not 1 order. This is important for business analytics and customer service, which are business facing services as opposed to client facing services.
As a Java developer I tend to feel Angular/JS developers do a completely different and non-overlapping job than me. I feel the same way towards HTML/CSS folks. As such, I don't recommend you try being both, you will stretch yourself too thin. However, a good working knowledge on a smaller project, such as you are suggesting, is certainly useful.
Welcome to SO. Your post will probably be closed/ignored for being to broad, etc. Very specific questions and answers are what this site is about. GL.
I am in the process of learning about microservices and there's one thing that I can't seem to figure out and I can't find any resources that give me a direct answer to this. The question is:
Do microservices involve only business logic and database interactions
or do they involve UI components like JS, CSS, HTML as well ?
There really isn't a notion of what tiers are included in a microservice itself, however generally speaking, when referring to microservices most of the time you're referring to some back end based app. That begin said - there are companies out there - two that I've talked to directly that are building "microapps" - basically the backend service, facade and a portlet like interface that can be plugged into a federated portal through a layer of orchestration.
For the Java folks - think fully encapsulated JSR-268 like components that are run as independent processes running within a portal itself.
A microservice can be a complete application including its own UI, business logic and data.
I working on a Saas application that will be using ASP.NET MVC 4 & SQL Server. I am planning to have a data layer (using EF5), a service layer (possible only have RESTful services), a DTO layer, and Web UI layer. Later on, I am planning to extend this application to mobile platform, for both Android & iPhone ... maybe windows tablet.
Usually, one would create a separate layer for domain objects where business rules are contained. However, in my case, if I did that, then I would have to replicate the rules again for android ... and yet again for iphone. So, I was thinking to have the business rules within the service layer itself. However, for whatever reason that doesn't feel right.
Any suggestions on this?
The presentation layer must be what it is.. just a presentation layer. Your business rules should not be there.
I understand that your DTO's will be the objects that will feed your clients (android, iphone, web,etc..), so there's no need to transfer your business objects to the UI. Keep your business layer isolated in the server side and make your clients work with it just to get the data they need to show.
My suggestion is to make the presentation layer agnostic of the business rules. Using this approach will make your solution scalable and easy to extend. Is a good way to apply separation of concerns.
Saying that.. You might be worried about how to share your DTO's across different platforms. I think the best approach would be to not feed your presentation layer with .NET objects since you are planning to use different programming languages and technologies in your presentation layer. JSON and REST could play very well for your problem.
I suggest to use Asp.net Web Api to work with json objects. Objective-c, Java and Javascript (for your Web UI) can work with this kind of objects.
You said that you have a service layer. The business logic should be behind it.
Business layer -> (shared business objects) -> service layer -> (shared DTOs) -> presentation layers
Where the presentation layers are MVC4, Android, IPhone etc. They can all share the same DTOs but serialized differently.
From a performance perspective, duplicating the rules for each platform is the way to go (because it separates the processing between different devices) however from a maintenance, consistency, etc. perspective you should place the business rules in a workflow that is within / parallel to the service layer.
http://msdn.microsoft.com/en-us/library/ee658103.aspx
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
I have started working in C# for almost a few months and I am looking for something more challenging and interesting. I use a media player called media monkey that supports custom vb scripts, well I made one that writes a file to a dir that has the current song playing, and is updated every time a new song is playing by rewriting what was there before.
Now I want to add this information to a database and keep a record of this and possibly add the information on my home page. I know I can hack a way for it to work, but I want to know what would be the "professional way" of doing things.
I came up with the following and got stuck. I would need an ODBC driver to connect to a database which seems messy, would a web service work? How would that work? Can a VbScript call a dll file to call upon a web service to modify data on a seperate server? Is that safe to do?
Many professional C# apps are n-tier. In your case, you would probably layer it like this:
On the server:
-Database Store
-Database Access/Business layer(sometimes two distinct components, depending on how complex the app is)
-Web Service
On the client:
-Web Service Client
-Any other layers to support client functionality.
So the Database Store would be something like some tables in an Oracle or Microsoft SQL Server, and would on your server.
Database Access/Business layer would be your code that retrieves and stores data to/from your database. It might also contain business objects, which are basically classes that have properties representing your data from your database. The benefit of the data access layer is that sometimes reading and writing to a database can require specialized code, and you don't want that code sprinkled throuought your application. So instead you can call functions in your data access layer that loads needed data into objects, so the rest of your application is just interacting with a regular old .NET object/class. These are called POCOs, which stands for something like Plan Old CLR Object. There are lots of variations on this of course, as people have taken different approaches to the problem of isaloting database access. Also it serves the purpose of minimizing breaking changes whenever the database changes. Since the database access logic is not sprinkled throughout the app, then there are fewer places that need to be updated if the database changes (such as adding new columns to a table or changing a name).
Sometimes the business layer will be it's own layer, and would contain most of the "logic" of the application. It would sit between the data access and web service layers. Using concepts from Service Oriented Architecture (SOA), you might have an authentication service, and a web request handling service. These services are a lot like a class that is always instantiated, there waiting to process requests. Your web request handling service would take a request, and maybe first call into the authentication service to verify credentials before honoring the request. SOA is one of those things I think should be used only when appropriate. It some cases just using Object Oriented techniques will give you the same benefits. Not always though. SOA, when done right, is more scalable, so it really depends on whether SOA offers you additional benefits that you need.
The Webservice would be responsible for receiving requests from the web, parsing/interpreting them, and acting on those requests by making calls into your business layer to update or retrieve data.
So the concept here would be that you could have many users of your service who publish their song updates through your service.
Your client would have a "web service client" layer which would be responible for formatting requests into messages, sending them to the web service, and retrieving messages from the web service. You would put very little application "logic" in your web service layer.
Now all this is probably overkill and inefficient for what you are wanting to do since you just want something for yourself, but it's the basic anatomy of a lot of webservice applications and would be a good learning exercise. The whole purpose of the layers is decoupling and simplicity. While more layers/components makes the application overall more complex, it means each component is simpler. This means it's easier to wrap your head around problems when you are only dealing with one component which interacts with only a couple other components(the sourounding layer). So there is a careful balance between few components and many components. Too few and they become monolithic and difficult to manage. Too many, and they become intertwined in complex ways. I have heard it said something along the lines of "If a class is getting too big and too complex, then split it up into a few more classes". In essence, don't start subdividing stuff for the heck of it just because it sounds like the right thing to do. Evaluate how complex your component is going to be before deciding if you want to split it up. Sometimes for simple cases your have a layer serving more than one purpose, for the sake of getting it done faster and making the overall design simpler. The point is, apply these concepts where appropriate. You will learn what is appropriate with experience, and you obviously understand that you can learn the most by "doing".
"Can vbscript call a COM component?" You can compile .NET DLLs with COM support. Many older things can call COM dlls.
I googled: vbscript dll
and got this: VB Script and DLLs
"Is that safe to do?" Your webservice will be where you would be most concerned with security. It's safe only if you design with security in mind and don't screw up. We all screw up sometimes though, which means there is no guarantee of it being perfectly secure.