I am learning general development strategies but there are a lot question in my mind about them. One of them is about creating application layer which shouldn't have dependencies Presentation layer.
For example, in MVC application lets say we have application services but this application services doesn't check validation for incoming data models from Presentation layer. It is only checked in controller via ASP.NET MVC validations also service layer doesn't include any authorization stuffs inside. All job is done in Presentation layer. Do you think that is it correct architecture ? Do i have to include all validation and authorizations inside service layer re-again ? If you say yes but how ??
How can i include authorization in service layer ? I really don't know how to control auhthorizations inside service layer. Duplicating validations in also service layer could be ok ?
After all Is it really worth to make such as design if i am sure presentation layer will never change ?
Validation should be in the domain layer. In a DDD application the domain (business) layer should own the validation since it knows most about itself. The service layer operates upon the domain and should handle errors, including validation errors, raised by the domain layer. Handling an error in this case could mean wrapping it in a service layer exception and returning an error code, logging the error, etc. Authorization should also be the responsibility of the service layer. This is not to say that the presentation layer (ASP.NET MVC) should not perform validation or authorization verification. Validation in the presentation layer is typically more light-weight than validation in the domain and service layers and is done in order to improve the user experience. After all, if most of the validation can be performed on the client side, why not do it and save a trip to the service layer? The same logic applies for authorization.
In regards to duplication of of validation logic there is no solution that will fulfill all cases and sometimes you have to accept a little duplication to reduce overall complexity and improve maintainability. The simplest way do do validation in the domain layer is using standard guards and throwing ArgumentException instances. In ASP.NET MVC the simplest way to do validation is using data annotation attributes. Often times it is easier to duplicate validation logic to some extent than it is to implement an all encompassing validation system. Moreover, there may be validation that can only be performed by the domain layer, which is another argument for keeping them separate.
Authorization in the service layer can be done in many ways and depends on the underlying technology used. If using WCF there are many guidelines for doing authorization.
Related
In a micro service architecture, Is it good to have separate DAO services for all the Business services or should I have all the layers intact in the service. In my case, I am building a small Banking application where in I have below services
cbs-accountsummary
cbs-payments
cbs-accounts
cbs-loan
cbs-deposits
So should I really require below services as well
cbs-accountsummary-dao
cbs-payments-dao
cbs-accounts-dao
cbs-loan-dao
cbs-deposits-dao
Or is it fine to have DAO as part of business services. I am really wondering how it goes in real life applications.
In micro-services architecture you split your Domain to micro-services and each micro-service will have its own: api, business logic and data access.
Your example
In your case for example the micro-service "cbs-payments" will have its own API exposed, as well as a business layer(the domain logic of the payments domain) and data access layer. The micro-service will be responsible for the whole scope of the request from api to data persistence. This could include api's, business logic, cache, database and other things.
Lets say if you have a Create payment api call. You would call your micro-service REST api like POST api/payments which would process the request, apply some business rules(validation and others) and save it to the micro-service specific database. All that code would be in your micro-service.
The confusion
Maybe your where working with systems where the the architectural split was not done based on the domain but on some other criteria.
Usually micro-services are split based on some Domain boundaries like in your example. Each of these micro-services are isolated. Regardless of business logic, data access logic or any other logic it is still part of that micro-service.
Usually people use DDD(Domain Driven Design) with micro-services. It is also a common approach to use Repository and Unit Of Work design patterns. You could create Generic Repository/Unit of Work classes which help in database interaction. If you are using micro-service architecture you can extract these generic implementation to some library and use them in each micro-service(extend them if needed). Still you would use that code in your micro-service code.
As already said, I would not go for separate DAO-Services. A Microservice should control all aspects for the bounded context it is responsible for, this includes persistence.
Imagine, if there would be seperate DAO-Services, what would prevent a client from modifying, via said services, the data of the Microservice itself? The Microservice applies business logic onto its domain objects and persists them or not (in case of business rule violation). You never want this to be circumvented. See "cohesive behavior" of Sam Newmans book Building Microservices.
Assuming you follow DDD and you have your Domain, Application and Presentation (Controller) Layers, should the Application Layer be completely decoupled from knowing anything about HTTP requests and all the other things that go with it such as cookies, sessions, etc.
To illustrate, say our CommentingService in Application Layer needs a value from a cookie named guestId. Should this value be passed in as a parameter to our service or can we pass the whole Request (HttpContext) object and let our service extract it from there.
Commons sense tells me that if I would want to reuse this Application Layer somewhere else I would want it to be decoupled from web.
Services
Yes, you will want to decouple your application layer from any web concerns.
Application layer is responsible for managing your domain objects like aggregates, repositories etc (orchestration).
Mostly you will go with next layer providing Rest Api functionality.
If you decompose it like that, you could use your API with CLI, Rest, Soap or whatever your business want you to provide.
Cross-cutting concerns
You will want to implement cross-cutting concerns in your application layer, because you do not want to reinvent wheel for every outside layer.
For example: security, caching, transaction managing logging.
It doesn't provide you with business capabilities, so you do not implement them in domain layer, but you can implement it in your application layer.
SETUP
At present I have a controller heavy spring MVC application. Its components are heavily guarded with spring security. Most of the datamodel fetching, form binding etc... is done within controllers.
I however see great value addition in using spring web flow.
However I would like to use web flow in a specific way.
First of all I would like the web flow to be like traffic police directing web requests to appropriate controllers inside every state (Along with form binding objects, request, session params etc...).
I would like the controller to ultimately determine direction of web flow like successful login or goto registration page. However it is web flow that will consume the decision and facilitate the transition to the next state.
This next state will in turn leverage mvc by invoking appropriate controllers.
This way spring web flow is just like a facilitator and does not contain too much decision making logic & business logic invocation calls.
This is important for me since controllers can get heavy with respect to services it invokes and can potentially invoke them in a multi-threaded approach. All this cannot be done in spring web flow definitions
QUESTION
My question is very simple and basic. Is Spring Web Flow designed to perform like this on top of Spring MVC?
Is it possible to designate just this traffic regulation and state flow functionality to web flow while preserving most of the control and service invocation logic inside the controller?
--Am I understanding anything wrong here? I want to get these questions cleared before
embarking along this path.
This may be a little late for you, but I'm not sure webflow will give you exactly what you want to achieve. You want a router, and that's not really what webflow was designed for. Webflow is used more for multi-page form type flows, and using it for much more risks running into the limitations of the framework. Webflow cannot be used to intercept all web requests -- only those initiated through the flow mechanism, and it has very strong opinions on what state transition is (for example, form/bean validation is the default, although it can be overridden if required).
It's not that it can't be used as a router, it's just that it's not designed for this so you're likely to find impedance from its form based design goals.
I have following architecture in my application.
Client (GWT) <--calls--> Servlet <--calls--> Service <--calls--> Dao
I want to make this architecture easier for changes.
For example: when I want return the inserted id of an object from the Dao layer, because I need it in the client, I have to update the service and the servlet layer as well. So for this little change I have to update all 3 layers (3 classes and 3 interfaces) makes a change on 6 places.
I see why I need the Dao Layer.
I also get why I need the service layer.
What I don't get is why the service layer can't also be a servlet. At the moment all my servlets do is forwarding the request to the service layer.
The Wikipedia Article about Java Servlets says:
Servlets are most often used to
1 process or store data that was submitted from an HTML form
2 provide dynamic content such as the results of a database query
3 manage state information that does not exist in the stateless HTTP protocol
1 and 2 are just database calls, which I make in my dao layer and the service layer makes extra business logic already possible.
3 I am currently not working with sessions. I don't have a login so far and I am just playing around with my architecture, but I think the service layer could handle this as well.
I want to know the cos and pros for this architecture change:
pros:
One layer less to update if a change happens.
cons
Service Layer gets complexer.
Thx for your answers.
You need the servlet layer because that is what allows access to the session.
Also, you don't want your service layer to need to know anything about HTTP since you want to be able to re-use the service and DAO layers in other applications (e.g. if you write a desktop application re-using those layers) and needing to include the servlet API would not make sense there.
If needed you could call the DAO layer directly from a servlet for simple cases in order to not duplicate methods in the service and DAO layers.
The servlet API has filters which are a good place to implement security in your web application.
You can use Spring Security if you are already using the Spring framework for your web application.
So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.
We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.
I was thinking something like the following:
Core - domain objects (poco's)
Data - Entity Framework (Code First) or nHibernate exposed as Repositories
Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
UI (MVC) - Controllers and Views.
This would all be tied together using a DI container such as Autofac.
We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.
So - does the above sound like a good overall architectural pattern for a pretty standard business application?
The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?
OR
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
Any thoughts would be really helpful as I don't know what best route would be.
Should we use a WCF service as our service layer facade in nTier application
Depends on if any other application than the MVC application is going to talk to the service.
MVC3 is the only app: You aint gonno need it
Other apps too: Sure. Do it.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming
Don't use the concrete service classes. Use the service interfaces. Problem solved.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API
I hope that you mean the same WCF service.
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.
Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).
In your mvc application you can consume the service by endpoint url.
Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.
Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))