I'm trying to implement Clean Architecture in a microservice, this service return JSON response. Do i need a presenter to present the response DTO or just send it back to the client
This was the difficult part for me to implement a Controller and Presenter for REST API following the exact diagram in the article by Uncle Bob Martin Clean Architecture because the architecture diagram example was for like a web page, so the architecture was for the replacement of MVC or MVP patterns.
But in case of a Microservice you don't need a View component and View Model.
And the most important thing is that you can not completely separate Controller and Presenter because you need to send a response to the microservice using the same interface you've used to get the input from the microservice to the Controller.
This is why I was really struggling to achieve the complete separation of Controller and Presenter. In case of Microservice or REST API, you need to make a Presenter to depend on Controller.
To do that, you need to create a Presenter Interface<I> within the Controller Component and make the Controller depend on the Presenter Interface<I>, and implement the Presenter Interface<I> in Presenter Component.
You can actually find this reference in the book by Robert C. Martin Clean Architecture, in Chapter 8 OCP: THE OPEN-CLOSED PRINCIPLE, in Figure 8.2.
In Clean Architecture the presenter is the component which converts the response model of a use case interactor into a response object which is most convenient for the view (e.g. it may format float number into strings with correct precision).
In case of an API service the presenter would do the same: conversation between service internal data structures and external data contracts (API).
For simple services the internal and external DTOs might be the same. In this case you could omit the presenter initially and introduce it later when needed.
In order to answer your question, I have to clarify two points:
Clean Architecture is a high level design pattern that advocates for a clear separation of concerns. A presenter is a component of the software design pattern Model-View-Presenter.
I guess that DTO comes from a different service, in that case Yes. If you want to implement Clean Architecture, you should not expose that DTO to the client.
If you get a JSON object from your Use Cases layer, then you can send it back directly to the client because this will not break the dependency rule.
Cramming some kind of a presenter into your REST API architecture would be a contrived complexity. An API, as the name suggests, is an interface through which your frontend gets data and presents it to the client. There's no presenting in the API itself.
Related
I have a question about responsibility of Controller and service about a piece of my code. I have a HTML form to save an article which can submit three image(thumbnail, summary and body) with their text. The body text can contains some images in Base64 format. I get them by a post Action which accept a DTO object to support all inputs.
The Tasks I want to do are:
Get DTO from client
Fetch images from body
Check Summary and body text rules
Check Fetched images rules
Check Thumbnail, summary and body image rules
Save them
I have a service layer here which has some class about checking article texts and images logics.
My question is that how should I act here. Which steps are for Controller and which ones for Service.
Step 2 is most confusing step to me. Should I do it in controller or just pass all DTO to Service to separate things itself?
Or about checking text, should I check for example summary text length in controller or it should be check by Service layer?
Can any one explain these to me?
Possible duplicate.
The responsibility of the controller, is to accept a request, invoke the processing, and respond according to the result of the processing.
Try to look at the SOLID principles and always try to apply them.
So first of all, DTO, it depends on your architectural design, but I would say that the DTO is the abstraction that allows you to decouple you Domain Model from the client model.
The DTO should be seen as the data representation between two layers, if the DTO crosses more than one layer, it probably isn't a DTO but a business or data entity.
) Fetch images from body
this looks like something you designed to be able to receive the desired data, but is not something your domain model cares about.
For example if your form allow you to save "Sale advert", which is made of few images and some text, probably this aggregation of data in your business layer (service), is represented by one or more domain objects, so the fact that you receive a body in whichever format, depends more on technology or transport, and should be transparent to your business layer.
A good example to help you find boundaries, is thinking about re-usability. How would you reuse your service layer if you were to use it from a WCF service for example?
Your service should always receive and expose Domain Objects.
Leave to the consumer component the responsibility to decode/encode.
3) Check Summary and body text rules (and all other checks)
seems to be a validation, but I cannot tell if this validation is only related to the domain.
Some validation is also done in the controller itself to check if the request is valid or not.
So if this check is done on the DTO structure, before you try to convert it, probably that is a controller validation, if instead, this validation is necessary to decide weather or not the input can be saved, well probably in this case it would be considered other's responsibility.
You mentioned:
for example summary text length
if this is a business rule, then I would place it in a validation object, responsible to validate the "summary text" or let's call it again "Sale advert".
The responsibility to save a domain object to a data store, is normally delegated to a Data Access Layer, which is coupled to the database structure and provides the abstraction to the business layer.
This can be done implementing a repository pattern or maybe using an ORM, I normally don't add logic to persist data in the business layer.
Another note, here you are asking about controller responsibility, but pay attention to your service "layer", I have seen often code where a huge service class, was encapsulating all the business logic and validation, that is very bad because again goes against most of the solid principles.
Look at the command query and decorator pattern, I love them because the really help you breaking down your code in smaller pieces with single responsibility.
If interest look at this example project on github (.net core).
I am still working on the documentation but should be clear enough.
While using a custom MVC framework I found that the view can actually access data in the model. That was a bit of a surprise because I always thought the V must go through the C. It was something like
//this is completely made up but not far off
serverside foreach(var v in Model.GetSomeList()) {
<div>#v.name</div>
}
Do many MVC frameworks in any programming language allow the view to access anything in the model? When do i choose what should go through the controller and what is ok to access from the view?
Usually that "Model" is really like viewmodel, not the business layer Model object, although it could be the POCO version of the business object. Basically, the view is bound to some poco without any business logic.
Information flow in classical MVC.
Data in MVC should not go from model through controller to view. That is violation of the original concept.
If you read the original definition of MVC design pattern you will notice that Views are meant to request the data from Model. And views know when to do it, because they are observing Model for changes.
Modern interpretations.
In the original concept you were meant to have small MVC triad for each element in the application. In modern interpretation (as per Martin Fowler), the model is not anymore any single object or class. Model is a layer, which contains several groups of objects. Each with a different set of responsibilities.
Also, with the rise of Web there was another problem. You cannot use classical MVC for websites. Theoretically now you could achieve it by keeping an open socket and pushing a notification to the browser every time you changed something in the model layer.
But in practice even a site with 100 concurrent users will start having problems. And you would not use MVC for making just a blog. Using such an approach for even minor social network would be impossible.
And that was not the only divergence from the original concept.
MVC-inspired patterns
Currently, along with classical MVC (which is not even all so classical anymore). There are three major MVC inspired patterns:
Model2 MVC
This is basically same classical MVC patter, but there is not observer relationship between model later and view(s). This pattern is meant to me more web-oriented. Each time you receive a user request, you know that something is gonna change in model layer. Therefore each user request cause view instance to request information from the model layer.
MVP
This pattern, instead replaces controller with a presenter. The presenter request data from model layer and passes it to current view. You can find patterns definition here. It is actually a lot more complex, and I, honestly, do not fully understand it.
In this case the View is passive and will not request any data from model layer.
MVVM
This pattern is closer to MVP hen to classical MVC. In this case the controller-like structure (which actually would be more then a monolith class) request data from model layer and then alters it in such a way as it is expected by the (passive) view.
This pattern is mostly aimed at situation where developer does not have full controller over views or/and model layer. For example, when you are developing some application where model layer is SAP. Or when you have to work with an existing frontend infrastructure.
FYI: what is called "MVVM" in ASP.NET MVC is actually a good Model2 implementation .. what they call "viewmodels" are actually view instances and "views" are just templates that are used by views.
This is common. If you look at the Wikipedia page for MVC, this is what it says for the view:
A view requests from the model the information that it needs to generate an output representation.
MVC is an architectural style, so some people change it as they see fit. From the design intentions of the architecture this particular question is certainly not frowned upon.
I've the following (theoretical architecture):
a view layer: a web site which show pages in Php
a business logic layer divided in two parts: one communicates with the view layer , the other consists of a java project
a data access layer which let the "two" business layer to communicate with two databases
The question is: can this be considered a MVC pattern?
No , MVC and VBD are not the same. This not classical MVC design pattern nor anything related to MVC. This is what newbies make, when they are told about "separation of concerns" for first time.
There is no controller nor anything remotely resembling a controller-like structure. Usually, the presentation layer is made up from both view and controller instances. But looks like the part, which is responsible for interaction, is missing. Basically, no separation between V and C.
For some strange reason the domain objects (ones, that contains business logic) on the PHP side have direct access to domain object on Java side. This means that they are interacting directly though services.
In MVC design pattern data access logic is part of model layer ( in form of data mapper or transaction scripts ). In this the seem to be separated.
There is direct two-way interaction between domain objects and presentation layer, which means, that presentation layer contains some of domain logic.
You have "JavaScript API" in domain objects. That's part of presentation logic.
Bottom line: the whole thing is a mess.
I wanna restrict model to calling to db only
while controller will call model, libraries or helpers.
I do not want to put logic in controller nor in the model to prepare data for views.
Now the logic for preparing all the arrays for views are done in controller. I am creating a library to separate this part as sometimes i feel it is overloading the controller
Hence, i want to create a library class and make controller build the view data before throwing it to the view. It is not exactly templating.
The thing is i do not know how to name it.. Any good suggestion ?
I am thinking view_builder, ui_builder, ui_components?
Cheers
Here's how I'd layer the app:
View
Controller
Service
Persistence
View is either desktop or browser or mobile-based.
Controller is tightly bound to view. It's responsible for validating and binding input to model objects, calling services to fulfill use cases, and routing the response to the next view.
Services fulfill use cases. They know about units of work, own transactions, and manage connections to resources like databases. They work with model objects, other services, and persistence objects. They're interface-based objects, but can be remoted or exposed as web services - RPC-XML, SOAP, REST or other.
Persistence is another interfaced-based object. The implementation can be relational or NoSQL; the important thing is that the interface expresses CRUD operations for model objects. If you use generics, it's possible to write one interface that works for all.
I wouldn't have model objects persist themselves. I'm aware of the "anemic domain model" pejorative, but I think more exciting behavior should center around the business purpose, not CRUD operations.
Good setup. I also sometimes use CI libraries to work out the kinks in a returned data array before passing it to a view. I also sometimes just use the model.
And good for you for thinking about names - I think all the ones you mention are fine; you could also think about naming your library something like data_structure or array_to_object - or something more specific to your own problem like friend_map or tag_cloud.
My advice: pick a name, and then don't be afraid to change it if something more descriptive comes along or the function of your library evolves into something else. Find+replace is your friend.
I'm slightly confused about what exactly the Model is limited to. I understand that it works with data from a database and such. Can it be used for anything else though? Take for example an authentication system that sends out an activation email to a user when they register. Where would be the most suitable place to put the code for the email? Would a model be appropriate... or is it better put in a view, controller, etc?
Think of it like this. You're designing your application, and you know according to the roadmap that version 1 will have nothing but a text based command line interface. version 2 will have a web based interface, and version 3 will use some kind of gui api, such as the windows api, or cocoa, or some kind of cross platform toolkit. It doesn't matter.
The program will probably have to go across to different platforms too, so they will have different email subsystems they will need to work with.
The model is the portion of the program that does not change across these different versions. It forms the logical core that does the actual work of whatever special thing that the program does.
You can think of the controller as a message translator. it has interfaces on two sides, one faces towards the model, and one faces towards the view. When you make your different versions, the main activity will be rewriting the view, and altering one side of the controller to interface with the view.
You can put other platform/version specific things into the controller as well.
In essense, the job of the controller is to help you decouple the domain logic that's in the model, from whatever platform specific junk you dump into the view, or in other modules.
So to figure out whether something goes in the model or not, ask yourself the question "If I had to rewrite this application to work on platform X, would I have to rewrite that part?" If the answer is yes, keep it out of the model. If the answer is no, it may go into the model, if it's part of the essential logic of the program.
This answer might not be orthodox, but it's the only way I've ever found to think of the MVC paradigm that doesn't make my brain melt out of my ear from the meaningless theoretical mumbo jumbo that discussions about MVC are so full of.
Great question. I've asked this same question many times in my early MVC days. It's a difficult question to answer succintly, but I'll do my best.
The model does generally represent the "data" of your application. This does not limit you to a database however. Your data could be an XML file, a web resource, or many other things. The model is what encapsulates and provides access to this data. In an OOP language, this is typically represented as an object, or a collection of objects.
I'll use the following simple example throughout this answer, I will refer to this type of object as an Entity:
<?php
class Person
{
protected $_id;
protected $_firstName;
protected $_lastName;
protected $_phoneNumber;
}
In the simplest of applications, say a phone book application, this Entity would represent a Person in the phone book. Your View/Controller (VC) code would use this Entity, and collections of these Entities to represent entries in your phone book. You may be wondering, "OK. So, how do I go about creating/populating these Entities?". A common MVC newbie mistake is to simply start writing data access logic directly in their controller methods to create, read, update, and delete (CRUD) these. This is rarely a good idea. The CRUD responsibilities for these Entities should reside in your Model. I must stress though: the Model is not just a representation of your data. All of the CRUD duties are part of your Model layer.
Data Access Logic
Two of the simpler patterns used to handle the CRUD are Table Data Gateway and Row Data Gateway. One common practice, which is generally "not a good idea", is to simply have your Entity objects extend your TDG or RDG directly. In simple cases, this works fine, but it bloats your Entities with unnecessary code that has nothing to do with the business logic of your application.
Another pattern, Active Record, puts all of this data access logic in the Entity by design. This is very convenient, and can help immensely with rapid development. This pattern is used extensively in Ruby on Rails.
My personal pattern of choice, and the most complex, is the Data Mapper. This provides a strict separation of data access logic and Entities. This makes for lean business-logic exclusive Entities. It's common for a Data Mapper implementation to use a TDG,RDG, or even Active Record pattern to provide the data access logic for the mapper object. It's a very good idea to implement an Identity Map to be used by your Data Mapper, to reduce the number of queries you are doing to your storage medium.
Domain Model
The Domain Model is an object model of your domain that incorporates behavior and data. In our simple phone book application this would be a very boring single Person class. We might need to add more objects to our domain though, such as Employer or Address Entities. These would become part of the Domain Model.
The Domain Model is perfect for pairing with the Data Mapper pattern. Your Controllers would simply use the Mapper(s) to CRUD the Entities needed by the View. This keeps your Controllers, Views, and Entities completely agnostic to the storage medium. This also allows for differing Mappers for the same Entity. For example, you could have a Person_Db_Mapper object and a Person_Xml_Mapper object; the Person_Db_Mapper would use your local DB as a data source to build Entities, and Person_Xml_Mapper could use an XML file that someone uploaded, or that you fetched with a remote SOAP/XML-RPC call.
Service Layer
The Service Layer pattern defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation. I think of it as an API to my Domain Model.
When using the Service Layer pattern, you're encapsulating the data access pattern (Active Record, TDG, RDG, Data Mapper) and the Domain Model into a convenient single access point. This Service Layer is used directly by your Controllers, and if well-implemented provides a convenient place to hook in other API interfaces such as XML-RPC/SOAP.
The Service Layer is also the appropriate place to put application logic. If you're wondering what the difference between application and business logic is, I will explain.
Business logic is your domain logic, the logic and behaviors required by your Domain Model to appropriately represent the domain. Here are some business logic examples:
Every Person must have an Address
No Person can have a phone number longer than 10 digits
When deleting a Person their Address should be deleted
Application logic is the logic that doesn't fit inside your Domain. It's typically things your application requires that don't make sense to put in the business logic. Some examples:
When a Person is deleted email the system administrator
Only show a maximum of 5 Persons per page
It doesn't make sense to add the logic to send email to our Domain Model. We'd end up coupling our Domain Model to whatever mailing class we're using. Nor would we want to limit our Data Mapper to fetch only 5 records at a time. Having this logic in the Service Layer allows our potentially different APIs to have their own logic. e.g. Web may only fetch 5, but XML-RPC may fetch 100.
In closing, a Service ayer is not always needed, and can be overkill for simple cases. Application logic would typically be put directly in your Controller or, less desirably, In your Domain Model (ew).
Resources
Every serious developer should have these books in his library:
Design Patterns: Elements of Reusable Object-Oriented Software
Patterns of Enterprise Application Architecture
Domain-Driven Design: Tackling Complexity in the Heart of Software
The model is how you represent the data of the application. It is the state of the application, the data which would influence the output (edit: visual presentation) of the application, and variables that can be tweaked by the controller.
To answer your question specifically
The content of the email, the person to send the email to are the model.
The code that sends the email (and verify the email/registration in the first place) and determine the content of the email is in the controller. The controller could also generate the content of the email - perhaps you have an email template in the model, and the controller could replace placeholder with the correct values from its processing.
The view is basically "An authentication email has been sent to your account" or "Your email address is not valid". So the controller looks at the model and determine the output for the view.
Think of it like this
The model is the domain-specific representation of the data on which the application operates.
The Controller processes and responds to events (typically user actions) and may invoke changes on the model.
So, I would say you want to put the code for the e-mail in the controller.
MVC is typically meant for UI design. I think, in your case a simple Observer pattern would be ideal. Your model could notify a listener registerd with it that a user has been registered. This listener would then send out the email.
The model is the representation of your data-storage backend. This can be a database, a file-system, webservices, ...
Typically the model performs translation of the relational structures of your database to the object-oriented structure of your application.
In the example above: You would have a controller with a register action. The model holds the information the user enters during the registration process and takes care that the data is correctly saved in the data backend.
The activation email should be send as a result of a successful save operation by the controller.
Pseudo Code:
public class RegisterModel {
private String username;
private String email;
// ...
}
public class RegisterAction extends ApplicationController {
public void register(UserData data) {
// fill the model
RegisterModel model = new RegisterModel();
model.setUsername(data.getUsername());
// fill properties ...
// save the model - a DAO approach would be better
boolean result = model.save();
if(result)
sendActivationEmail(data);
}
}
More info to the MVC concept can be found here:
It should be noted that MVC is not a design pattern that fits well for every kind of application. In your case, sending the email is an operation that simply has no perfect place in the MVC pattern. If you are using a framework that forces you to use MVC, put it into the controller, as other people have said.