5 ms·

I don't think events themselves are the issue so much as mutability. When you combine them you end up with changes that ripple through the entire program, maki

I don't think events themselves are the issue so much as mutability. When you combine them you end up with changes that ripple through the entire program, making everything incredibly difficult to reason about. A better approach I think would to use FRP (functional reactive programming) on streams of events which eventually sends messages to an agent (one for each category of concern). This enforces a clean separation and allows for simple inspection and testing. It also has the added benefit of allowing you to scale easily by putting the different agents on different machines, or even sending messages to one of several identical agents randomly.

Spearchucker 13y ago
Can't comment about FRP, but can tell you that events can ripple through an entire system, but don't have to. The back story to that is that you need to put some effort into design. I've been using an event-based design as the basis for all native apps I've built since 2004, and it's evolved into something that's predictable and obvious - primarily because of separation of concerns. For a simple example, here's a short description of the client I use for my blog: https://www.wittenburg.co.uk/Diagram.aspx?id=5919c0a5-dcb5-4e5d-be02-80932dc29fc4&url=Images/clientdesign.png https://www.wittenburg.co.uk/Diagram.aspx?id=5919c0a5-dcb5-4... The blog post describing the diagram is here: https://www.wittenburg.co.uk/Entry.aspx?id=5919c0a5-dcb5-4e5d-be02-80932dc29fc4 https://www.wittenburg.co.uk/Entry.aspx?id=5919c0a5-dcb5-4e5... In this approach the model (I call them application entities) is the only part of the system that can raise application-wide events. These are limited to things that happen to the model, eg. Login; per collection, things like Selected, Added, Removed; and per entity, things like Saved, and Deleted. The UI raises events (keyboard/mouse/etc), but their scope is limited to the UI. There's a service agent that abstracts asynchronous calls to a service, and it raises an event once an async call completes, but that is only visible to application components (Operations, in the linked post). My specific implementation of this design is based on the architecture of Microsoft Office apps (the idea started formulating after working with Word's document object model). It's clean and like I mentioned above, predictable.
- adamauckland 13y ago
  That's similar to how I'm tending towards. Controllers shouldn't contain the actual business logic, that's for the application layer. Controller -> Application Objects -> Model -> View -> Controller That way, the 'web page' controller can be replaced by a 'web service' controller or a 'command line' controller and the application logic remains untouched. Spaghetti controllers are a result of not separating concerns. I also agree with your event compromise. There are always going to be events that need to be broadcast systemwide (logout), but they should be limited. I've been toying with using a message queue instead of events, it may work, it may not...

Spearchucker 13y ago

Can't comment about FRP, but can tell you that events can ripple through an entire system, but don't have to. The back story to that is that you need to put some effort into design. I've been using an event-based design as the basis for all native apps I've built since 2004, and it's evolved into something that's predictable and obvious - primarily because of separation of concerns. For a simple example, here's a short description of the client I use for my blog: https://www.wittenburg.co.uk/Diagram.aspx?id=5919c0a5-dcb5-4e5d-be02-80932dc29fc4&url=Images/clientdesign.png https://www.wittenburg.co.uk/Diagram.aspx?id=5919c0a5-dcb5-4... The blog post describing the diagram is here: https://www.wittenburg.co.uk/Entry.aspx?id=5919c0a5-dcb5-4e5d-be02-80932dc29fc4 https://www.wittenburg.co.uk/Entry.aspx?id=5919c0a5-dcb5-4e5... In this approach the model (I call them application entities) is the only part of the system that can raise application-wide events. These are limited to things that happen to the model, eg. Login; per collection, things like Selected, Added, Removed; and per entity, things like Saved, and Deleted. The UI raises events (keyboard/mouse/etc), but their scope is limited to the UI. There's a service agent that abstracts asynchronous calls to a service, and it raises an event once an async call completes, but that is only visible to application components (Operations, in the linked post). My specific implementation of this design is based on the architecture of Microsoft Office apps (the idea started formulating after working with Word's document object model). It's clean and like I mentioned above, predictable.

adamauckland 13y ago
That's similar to how I'm tending towards. Controllers shouldn't contain the actual business logic, that's for the application layer. Controller -> Application Objects -> Model -> View -> Controller That way, the 'web page' controller can be replaced by a 'web service' controller or a 'command line' controller and the application logic remains untouched. Spaghetti controllers are a result of not separating concerns. I also agree with your event compromise. There are always going to be events that need to be broadcast systemwide (logout), but they should be limited. I've been toying with using a message queue instead of events, it may work, it may not...