But would it reside in the model layer or the controller layer? Both? How is it different from just serializing & storing the request object of your MVC dispatcherAnother use for this kind of complete Audit Log is to help with debugging. Of course, it's old hat to use log files for debugging production problems. But Event Sourcing can go further, allowing you to create a test environment and replay the events into the test environment to see exactly what happend, with the ability to stop, rewind, and replay just like you can when executing tests in a debugger. This can be particularly valuable to do parallel testing before putting an upgrade into production. You can replay the actual events in your test system and test that you get the answers you expect.
Alternative paradigms to MVC?
Moderator: General Moderators
Re: Alternative paradigms to MVC?
I think this part makes me understand part of the benefit:
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Alternative paradigms to MVC?
My guess is that the Event system would be available everywhere -- so anything could add events. So the Front and Action Controller, Models and View, plus Helpers would all add to this "history."
(#10850)
Re: Alternative paradigms to MVC?
Not quite. Your aggregate root objects are what add to the event store. However, because they are the aggregate root objects, this basically means nothing can happen without the possibility of the event store knowing about it. I realise this is a cyclic/recursive explaination, but it's impossible for anythng to happen without the event store knowing about it, because nothing can happen unless an event is raised that represents the Command issued.
Re: Alternative paradigms to MVC?
So if I understand, the way it'd benefit me is
- ability to tell a user what they did to get into a given state during a support call
- ability to 'undo' & 'redo' all actions, ala the 'actions' on photoshop
- ability to replay back from the actions, ala photoshop batch processing, or setting up almost like a 'macro' language for the users to program actions without typing commands
- ability to have the users opt in to collection of 'anonymous usage data' for reporting back to me to improve the software
What's the best way for me to start using it? I read the Fowler article.. should I just start playing around? Or would I be wiser to study up for a while before even attempting this? I want to retrofit it onto an existing system, its well unit tested.
- ability to tell a user what they did to get into a given state during a support call
- ability to 'undo' & 'redo' all actions, ala the 'actions' on photoshop
- ability to replay back from the actions, ala photoshop batch processing, or setting up almost like a 'macro' language for the users to program actions without typing commands
- ability to have the users opt in to collection of 'anonymous usage data' for reporting back to me to improve the software
What's the best way for me to start using it? I read the Fowler article.. should I just start playing around? Or would I be wiser to study up for a while before even attempting this? I want to retrofit it onto an existing system, its well unit tested.
Re: Alternative paradigms to MVC?
If you have some time, Greg Young's talk gives some insight into it. I'm yet to implement Event Sourcing into existing functionality, so I will probably end up giving inaccurate advice.
http://skillsmatter.com/podcast/open-so ... perspecive
http://skillsmatter.com/podcast/open-so ... perspecive
Re: Alternative paradigms to MVC?
Thats a good linkRe: Alternative paradigms to MVC?
MVC was originally designed to handle GUI systems, not web, and it is quite old. There have evolved many derivatives that modify some of the original goals and change the way it works. Actually, even the "MVC" known from frameworks is not a real MVC, but one of its derivatives that is close to "MVP with Passive View". In the recent years, the pattern has been adapted to the web environment, thanks to the Java guys which designed two approaches to it known as Model-1 and Model-2.
The basic MVC family is:
- Model-View-Controller - the original design pattern, different from things we know from frameworks.
- Model-View-Presenter - the role of view and model is decreased in favour of "Presenter", a super-controller, which deals with some model-specific and view-specific issues.
- Passive View - a modification to the two above that removes the connection between view and model (originally, the data are retrieved directly by the view through a reference and do not go through the controller).
- Hierarchical MVC - adds a hierarchy of controllers to the original MVC.
- Presentation-Abstraction-Control - adds a hierarchy of presenters to the original MVP.
- Model-View-ViewModel - ViewModel is a "model of view", acting as a data converter between model and view. This pattern lacks standarization, so it is sometimes hard to say, what it actually is.
A good lecture about these patterns and the concepts behind them is the website http://martinfowler.com/eaaDev/ by Martin Fowler, a specialist in software development and agile methodologies.
So, even in the "area of MVC" there is a lot to say, because the approach introduced by Ruby On Rails and adapted by 90% of web frameworks is not the only one.
The basic MVC family is:
- Model-View-Controller - the original design pattern, different from things we know from frameworks.
- Model-View-Presenter - the role of view and model is decreased in favour of "Presenter", a super-controller, which deals with some model-specific and view-specific issues.
- Passive View - a modification to the two above that removes the connection between view and model (originally, the data are retrieved directly by the view through a reference and do not go through the controller).
- Hierarchical MVC - adds a hierarchy of controllers to the original MVC.
- Presentation-Abstraction-Control - adds a hierarchy of presenters to the original MVP.
- Model-View-ViewModel - ViewModel is a "model of view", acting as a data converter between model and view. This pattern lacks standarization, so it is sometimes hard to say, what it actually is.
A good lecture about these patterns and the concepts behind them is the website http://martinfowler.com/eaaDev/ by Martin Fowler, a specialist in software development and agile methodologies.
So, even in the "area of MVC" there is a lot to say, because the approach introduced by Ruby On Rails and adapted by 90% of web frameworks is not the only one.
Re: Alternative paradigms to MVC?
In the talk they mention 'commands' get sent to a domain model, which does some processing, and then generates an 'event' describing the side effects that goto the event store. However in Fowler's article he just mentions 'events' that get logged, then sent to a domain model for processing.
Which is the "proper" way to do it? In the first example, with both events & commands, "where" are the events going? So my controller instantiates a command, and a domain model, and passes the command to the domain model. Does my domain model return an event object, and then the controller logs it?
Which is the "proper" way to do it? In the first example, with both events & commands, "where" are the events going? So my controller instantiates a command, and a domain model, and passes the command to the domain model. Does my domain model return an event object, and then the controller logs it?
Re: Alternative paradigms to MVC?
MVC distinguishes between two types of models: passive and active. Active models can change their state spontaneously, so they must generate events to notify views etc. when a state has been changed, so that they can redraw themselves. Example: a file copying window which shows the progress. The model performs the actual copying and produces two types of events: progress proceeds and copying finished. The view registers in the model as an observer, so it knows, when to redraw the progress bar and when to hide the window.
However, events have no practical meaning in the web environment due to the stateless nature of HTTP protocol. Here, the view only retrieves some data from models, generates output and pushes it to the browser. There is no way to notify the browser that the model state has been changed and the page should be refreshed, so here we use only passive models which accept commands and produce data only.
However, events have no practical meaning in the web environment due to the stateless nature of HTTP protocol. Here, the view only retrieves some data from models, generates output and pushes it to the browser. There is no way to notify the browser that the model state has been changed and the page should be refreshed, so here we use only passive models which accept commands and produce data only.
Re: Alternative paradigms to MVC?
In the few implementations we've er.. implemented here, the commands are also the events. I think it needs to be pointed out that, in the context of Event Sourcing, events are not "events" per-se. They are Commands that record the Action/Event of a user. So there doesn't have to be a "$this->raiseEvent()" or similar. I think in terms of "fitting it in" though, I would go for the controller recording the events.josh wrote:In the talk they mention 'commands' get sent to a domain model, which does some processing, and then generates an 'event' describing the side effects that goto the event store. However in Fowler's article he just mentions 'events' that get logged, then sent to a domain model for processing.
Which is the "proper" way to do it? In the first example, with both events & commands, "where" are the events going? So my controller instantiates a command, and a domain model, and passes the command to the domain model. Does my domain model return an event object, and then the controller logs it?
Re: Alternative paradigms to MVC?
Let's say my model adds a random number 1-5 to an input. How do I get & store the output? Does the model modify the command and return it back to the controller? Or a more deterministic example, lets say I pass a Login command to user model, how do I find out if it failed or not if the only architectural concept I have is the command?
Re: Alternative paradigms to MVC?
I don't think Login is a command, as it's (generally) not changing anything.josh wrote:Or a more deterministic example, lets say I pass a Login command to user model
Re: Alternative paradigms to MVC?
Well in that video Jenk linked, he said if my business users think of a query later, event sourcing will be able to answer that query. Well I am thinking of a query that involves looking at a user's login patterns maybe. So if it cannot answer that query then that guy must have lied 
But seriously, that guy said even a user looking at a page could be an event in the video presentation Jenk linked.
Also perhaps I do want changes upon the login command. Notify someone if too many logins from same IP, too many IPs per account, too many failed attempts on one IP, etc..
An example query I might want to do is "If a user fails to login more than once right after signup, does that correlate with them not completing the transaction"
But seriously, that guy said even a user looking at a page could be an event in the video presentation Jenk linked.
Also perhaps I do want changes upon the login command. Notify someone if too many logins from same IP, too many IPs per account, too many failed attempts on one IP, etc..
An example query I might want to do is "If a user fails to login more than once right after signup, does that correlate with them not completing the transaction"
Re: Alternative paradigms to MVC?
The simplest approach, and often favoured from what I have read, is to use an exception whereever a command/event cannot complete. In the login example, a LoginFailedException.josh wrote:Let's say my model adds a random number 1-5 to an input. How do I get & store the output? Does the model modify the command and return it back to the controller? Or a more deterministic example, lets say I pass a Login command to user model, how do I find out if it failed or not if the only architectural concept I have is the command?
This stems from the CQRS side, where a command should not have a response (in other languages this essentially means all command methods have a return type of void) you either ask a question (which should not alter the answer), or you issue a command - never both at the same time. This is right from the top to bottom - including user actions.
Re: Alternative paradigms to MVC?
What about the event sourcing side? Event sourcing promises to answer any query I ask, right? I'd like to ask a query about user logins. Maybe I'm making a "download manager" and it should track IP accesses to each account and lock the user out. I gave a few examples. Are you saying its impossible to build a system that does this while adhering to CQRS?
What about logging 'page views' like explained in your video. My question is how do I track my reads. I view a login as a read. Throwing an exception doesn't make sense to me I thought I'm only supposed to use those in "exceptional" situations?
I still don't get how CQRS & event sourcing are related? They seem to solve two unrelated problems?
In another video they talk about asynchronous commands. Example, user asks to add item to cart, and its taking a long time so after 2 seconds we decide to tell them we'll email the results. Doesn't this sort of imply commands yet again need results?
What about logging 'page views' like explained in your video. My question is how do I track my reads. I view a login as a read. Throwing an exception doesn't make sense to me I thought I'm only supposed to use those in "exceptional" situations?
I still don't get how CQRS & event sourcing are related? They seem to solve two unrelated problems?
In another video they talk about asynchronous commands. Example, user asks to add item to cart, and its taking a long time so after 2 seconds we decide to tell them we'll email the results. Doesn't this sort of imply commands yet again need results?