In a MVC web application, I often send emails.
I usually do it in the controller, as I load all my views from the controller (including email views).
Now, however, I have some code where the email sends from the model.
Which tier is email generally sent from? Does it matter? Does it need to be consistent?
A controller should ideally be like an operator that connects a view to a model. This either belongs in the model or service layer.
I would argue that this belongs in the Model layer only if you have a model object that is solely responsible for sending e-mails. You don't want to comingle presentation and logic, that's the whole point of separation of concerns in Model-View-Controller.
This type of logic should reside in a service layer. You could then use dependency injection to inject the service into the controller and call EmailSenderService.sendEmail();
Related
I'm going to create an api with api-platform and I want to separate my business logic from framework.
For example I want to allow users to register new accounts and POST: /user is good for that. Api-platform is doing all the magic (handler request, validate data, save new user (doctrine), return response). But my business logic wants to send invitation email and make other things during creating new user. How should I do that to be fine with api-platform?
Should I create custom operation POST: /register, inside call my use-case register($user)? Should I create custom repository interface and inside save(User) implementation call POST: /user?
Or should I use event system and split my "big" use-case (register) to small ones depends on what my business logic need to do (validate data, send invitation email, etc.)? And if I want to register new user from CLI my command has to use all of this small use-cases?
Or should I completely forget about all api-platform magic and if my business logic is more then CRUD I have to care of everything by my self (validate data, save to DB, send email, etc.)?
There are a places for custom business logic https://api-platform.com/docs/core/extending/.
Good point to add business logic are Data Persisters. I can use there my own Repository to save user, send email, etc.
I am trying to understand and use the MVC without a framework, until now I clearly understand what is the role of Model, View and Controller and how are they made.
But I have one question. If the Controller is a class with methods for every action in thew View, and in that method we communicate with the Model and ask some data or send some data, and then send that data to the view that we choose to display. My question is how we call that method from view when we need to send some data from view to controller?
Let say that we have a page with all users and when we click one user we want information about him and we send his id with post or get and we have a UserController with a GetUserInformation method wich communicate with model send the id receive the information set it to the view and call view() to show the information.
How do we call this method from View when the client clicks that user?
We made another file between them and send the user to that file and in that file we instantiate a controller object and call the method? But if we do that how is that file called in MVC?
And there are a lot of example, like login, add a user and so on when we need to call a method from controller and send some data or just call it without send data.
The general idea is how we call a method from a Controller object on an action in html page?
Since you have multiple php posts, I will assume that you are referring to implementing MVC or MVC-inspired architecture in context of web applications.
First of all: controllers are not responsible for passing data from the model layer (not a "model class") to the current view. The controller in MVC is only responsible for altering the state of the model layer (and in extremely rare cases - the current view's state) based on the user's input.
The second thing that you have to understand is the request-response nature of php. The instances in your application do not live past the execution of the site's code.
As for the view, its task is to create a response, which gets sent to a user. The "user" for your web application is not a human. Instead, what actually gets the response is a browser. And the browser does not get "the view". It only receives the response that was produced by the view.
Therefore:
It is not possible, in correctly implemented MVC-based web applications, for a view to call methods on the controller because:
you are not interacting with a view, but with a response
the view and controller are both already destroyed
P.S: at the beginning you wrote "until now I clearly understand what is the role of model,view and controller and how are they made", but it is clearly untrue.
Is there a practical way to access the attributes decorating a controller or action from a Message Handler/ DelegatingHandler?
From the diagram on Pedro Felix's blog entry, it looks like Message Handler's are too early in the pipeline and the info won't be available until the Controller Dispatcher Message Handler runs. Correct?
About my use case:
I'm working with the Thinktecture identity model, and it would be useful to be able to look for the AllowAnonymous attribute in the AuthenticationHandler.
By nature, this seems to be the wrong place to implement it. As you have noted, Message Handlers work across all requests and responses. If you depend on an attribute, this would naturally be a filter. So I suggest you follow that route.
In fact in the handler you cannot assume there is going to an ApiController or an action. Handlers can be equally used on clients.
I am building an MVC application (using the Zend Framework).
When users first register, the applicaiton sends them an email. My question is, where should I trigger this email from? The model or the controller? My thoughts are as follows:
In some ways, the model makes sense, since sending a registration email is part of my business logic. Users must click the link in the mail to validate their email address.
But by putting it in the model, I am 'encumbering' the model. The model's registerUser action is then only useful within the context of an application that needs emails sent for every registration.
Instead, by triggering the email from within the controller, my controller would be a litter 'fatter', but my model a little more 'fine grained'.
I have written an email service which actually configures and sends the email, and I think this is a good design decision. I am really just asking where I should be calling this service from.
Your thoughts are most appreciated!
According to Zend Framework's definition of MVC, you should put send the email from the controller:
Controllers...decide which view to display based on the user's request.
Models, on the other hand, contain:
...basic functionality behind a set of abstractions.
An email may be considered a "view" in that it displays information to the user. It is the controller's job to activate this "view."
In my opinion, I would want this in the model, as I would consider this an assumed process of the create user method, rather than any specific interaction with the user making the request.
In other words, since I would always want this email sent, regardless of the source of the request, I would identify this as a natural byproduct of the create user action, similar to a record being saved in a database.
You might want to look into using something like NServiceBus to queue messages to be sent to your Email Service.
This way you can have NServiceBus subscribe to an event that occurs and omit any manual firing of the email service etc.
Ultimately you want a failsafe way of ensuring your messages get to the intended people. This kind of framework will greatly help you ensure that this happens.
Alternatively you could store the emails to be sent inside your database and have your email service check the database queue every x minutes for new emails to send and omit the need for triggering the email sending.
Again, doing it this way will ensure at the least that the emails get sent. Should the network go down or some other disruption occur during the sending of each email you can simply leave them in the queue until the network comes back up.
We are writing an application hosted in Excel 2002 (groan). One requirement is that, during certain operations, we submit progress messages to the user from the business layer. However, these messages can be displayed at multiple sites, one being the Excel status bar, and another being a label on a form, and possibly others in the future. In some situations, we desire to only post the message to the Excel status bar, in others, just the label on the form, and in others, both.
Currently, we have a message "hub" to which business logic can post status messages. The Excel status bar and also the form label both observe this hub, and if any messages are posted, both intercept the messages and display them- similar to mass mailings via a post office, where the sender is unconcerned with the destination.
First: Is this a generally accepted pattern?
Second: Would it be prudent for the business layer to have knowledge of the destination to which it needs to post a message? Even though the business layer is relatively decoupled from the UI through the use of the post office, what is your opinion of imbuing the business layer with, essentially, address/target/destination information?
Thanks.
If you want to stick with the conventional pattern for this type of problem then you will want to look into the Model-View-Controller (MVC) design pattern. The purpose of the pattern is to decouple business logic from the GUI(s). It allows for one model (business logic) to drive multiple different GUIs.