Suppose the business layer is consumed by web and some of the business layer's functionality is open to public also as REST web services.
Would you do input validation for business logic at presentation layer (web or REST web service) or in business layer and capture the validation errors (thrown by business layer) at presentation layer?
(Specifically spring framework is in use)
When in doubt, it is generally better to put business logic (incl input validation logic) in the business layer because
You may be dealing with multiple presentation mediums (e.g., web GUI and API)
You don't want to repeat code and manage two instances of that logic
Good frameworks will allow you to define such logic in a common place and support catching issues early (e.g., in the presentation layer), which is usually a more intuitive (fail fast), more scalable (front end catches it) solution.
However, if your framework(s) do not support this capability, you should prefer consistency and maintainability and put the logic in the business layer.
I reccomend implementing validation in all layters. I do the UI so the user experience is high, with immediate feedback. But I never trust the data provided by the UI (think a user who disables JS). Now how detailed your server-side validation goes is up to you. But you want to avoid having your user have to suffer through a full round trip to the server if you can.
Violations of business rules should always happen in the business layer. Whether you allow for proactive checking or not is a design decision, as is whether you want to do eager checking on the client to avoid round-trips.
Related
If I need to write a simple webapi which need to get/create/update/delete of the products. Is this really need a business layer.
I am using Entity Framework which I understand this is similar to Repository Pattern.
If my webapi application is very simple which not much complex business logic e.g. bank reconciliation etc
Do i really need to have a business logic layer? Can i just have a service layer which create products / remove the products etc..
No, it is not necessary at all to have a business layer! (with a disclaimer)
Let me support my argument and address your concern
One of the most basic design principles of software engineering is KISS. If you feel the business problem you are solving is pretty simple then why to make code complex by introducing unnecessary layers.
Not having the 'business layer' is not a crime. It is well supported by the community as well that's why in one of the community and industry loved framework Spring there is a module called spring-data-rest exactly supporting design you are proposing (simple code with business layer and on top without explicit web layer)
The last argument evolutionary approach. With the increasing complexity of system and technology community released that system and code complexity should be evolved (thought process every well explained here). Don't try to think about future today (again referring to another basic design principle YAGNI). (Explaining disclaimer here) So start from simple and if in future you felt the need of having separate business logic layer because you got to write some actual business solving code then introduce that layer and evolve it!
I think these are conceptual questions, but for example, can we have a monolithic application that renders the pages and assembles the views (back and front together) or a monolith that is an api for a frontend application? And in the case of microservices, we can have microservices that render the pages or will always be APIs for consumption by a frontend application (or any other)?
Maybe!
Microservices usually means dividing your system into business contexts as opposed to software implementations.
So if the business context is, for example, the user experience, it makes sense that you put all of it in one place. User experience is mostly implemented in a webclient or mobile app layer, but can be heavily affected by a backend layer that serves those clients. In this case, bundling them together within the same code base and deployment cadence makes a lot of sense.
This "experience" microservice should have clear boundaries, though. Persisting things in a database is not part of the experience as a simple example.
In order to design architecture for an enterprise application which has many input validation that must be done on both server and client, what is the best practice? What’s your opinion about having same JavaScript functions with known parameters and execute them on server and client simultaneously?
I have many validations must do same in client and server and i want to prevent code redundancy, the using of custom validation is not the point, the point is finding a way to preventing of duplicate code in client and server.
I want a right architecture not a technologically idea.
The business logic of an enterprise application should be encapsulated on business layer.
The question is: are input validation business logic??
From my point of view some input validation ensure data consistency and should be busines logic. It's an architectural analysis.
Another consideration is the client.
How many client do you have?? Web, android, ios... you have to implement client validation for each. But the business layer remains the same.
My answer is: you are the architect, take in mind application constraints and the above considerations and find a criteria to deploy the validation in server or client.
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
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.