7 ms·

This sure looks like MVC, but they call the Controller "operations". The MVC abstraction has an issue with web applications, since the request-response cycle d

by scrame 14y ago

This sure looks like MVC, but they call the Controller "operations". The MVC abstraction has an issue with web applications, since the request-response cycle doesn't provide feedback as directly as the hardware-monitor-software cycle that the pattern was originally designed around. However, if the problem is that you are putting too much "logic" into your controllers, you should probably find a better place for it. In Java/Spring-MVC, there is a typical class hierarchy of Controller -> Manager/Service -> DAO. The extra level of indirection is a very handy place to put business logic, then each class in the tier has a dedicated function: Controller -- Parses input, delegates the action and returns the response (rendered by the view). Manager -- Handles sanitized data, encapsulates business logic and makes calls into the Model / Data layer. DAO -- Interfaces with the data store, makes sure only good data goes in, and appropriate responses are returned. This approach doesn't seem to offer anything more than that, except for putting a label on the messaging between subsystems, but those operations are not well defined (at least in this piece), and seem like another nebulous way to bury logic. It seems like this problem has arisen from a rather narrow reading of what an MVC system should be, as in, not having utility libraries because they aren't strictly an M a V or a C. *edit: formatting.

edwinnathaniel 14y ago
This article reminds me of Struts2 http://en.wikipedia.org/wiki/Apache_Struts http://en.wikipedia.org/wiki/Apache_Struts MVC with "action" (or event, similar semantics). Speaking of Java/Spring-MVC approach, I tend to have a mix approach of Service and Repository (since DAO seems to be getting a lot of bad-rep, time to pick a new name :D). Controller -> Service (SOAP) or Resource (REST) [although Resource could simply forward to Service as well) or Controller -> Repository (for specific entity that requires no interaction with other entities) Unfortunately the Service layer is necessary in the situation where there are 2 or more domain models need to interact with each other. This seems to help writing test-automations by splitting the tests into 2 categories: 1) End-to-End w/ mock repository 2) Integration only at Repository level using in-memory DB (Derby, H2) By doing this, we were able to speed up the test significantly. I believe in Rails, you're tied with ActiveRecord and would require real database (be it SQLite3). There may be open source libraries that can intercept AR calls and re-route it to either fake DB or just simply fake 'em all, but not sure how popular/complete they are.
- scottschulthess 14y ago
  Well I think it depends, sqlite can behave as an entirely in-memory database I think - so what would be the difference between that and a pure ruby in-memory database, really? If you want to just fake 'em all, which does not sound particularly ideal, people just generally mock em
  - edwinnathaniel 14y ago
    Yes, my bad for not clarify it: mock the repository part, but not to mock as an entire ActiveRecord. for example: FriendsRepository.java is an interface that can be mocked during unit-test while the integration-test would use the actual implementation. I know that the Java solution tend to be brittle because it somewhat forces people to have 1 interface, 1 class implementation (the mock implementation would be provided by mocking library).
cirwin 14y ago
It's very similar you're correct, particularly when you add in the Manager/Service layer (something that I hadn't spent enough time investigating). The main advantage of Operations over controllers is that they're fully composable. You can take the operation that logs a user in (which displays the login screen, and awaits the user typing a username and password) and use it as a sub-part of any other operation. In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. I'll certainly be following up with more details, and some actual code.
- scrame 14y ago
  Right, but in an MVC web-app, the Controller defines the "end-point". Meaning it should end there. The composition of different pieces of functionality should be happening in the area of the business logic. I understand the motivation, and have come across several situations where I wanted "controllers calling controllers", but ultimately, you're repurposing a piece of the architecture to do something it shouldn't be doing. A controller handles the input into the system, it shouldn't be defining a workflow. > In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. That just sounds backwards to me. Are talking about creating dynamic endpoints? That sounds like a much bigger headache than composing stuff in a service layer. MVC can be a little ambiguous, and with web-frameworks it can be hard to see that each piece is actually a subsystem. The Model isn't just your model class, its the model class, the DB and the ORM library you are running. Similarly, the View is the entire response / template rendering subsystem. The part that is addressed in the framework is mostly the "controller" subsystem, which is a way of organizing code so that the actual "controllers" can do the primary work of sanitizing input, delegating function calls and returning the output to the View system. Again, MVC is just a pattern that doesn't fit perfectly in the web request/response cycle, which then necessitates a pattern to handle the leakage (in my case I'm talking about the service/manager pattern). However, I just don't see your suggestions that MVC is "dead", or how this system is radically different. It seems like it is just semantics.
- 14y ago
kreek 14y ago
This looks like MVC to me as well, except what MOVE is calling operations I would call commands. There are quite a few MVC frameworks that work like this, including PureMVC which has been implemented in almost every OOP language http://puremvc.org/ http://puremvc.org/.
calinet6 14y ago
Yep. It's MVC with eventing (often found in most UI frameworks anyway). Definitely fits within the broad paradigm of MVC.

by scrame 14y ago

edwinnathaniel 14y ago

This article reminds me of Struts2 http://en.wikipedia.org/wiki/Apache_Struts http://en.wikipedia.org/wiki/Apache_Struts MVC with "action" (or event, similar semantics). Speaking of Java/Spring-MVC approach, I tend to have a mix approach of Service and Repository (since DAO seems to be getting a lot of bad-rep, time to pick a new name :D). Controller -> Service (SOAP) or Resource (REST) [although Resource could simply forward to Service as well) or Controller -> Repository (for specific entity that requires no interaction with other entities) Unfortunately the Service layer is necessary in the situation where there are 2 or more domain models need to interact with each other. This seems to help writing test-automations by splitting the tests into 2 categories: 1) End-to-End w/ mock repository 2) Integration only at Repository level using in-memory DB (Derby, H2) By doing this, we were able to speed up the test significantly. I believe in Rails, you're tied with ActiveRecord and would require real database (be it SQLite3). There may be open source libraries that can intercept AR calls and re-route it to either fake DB or just simply fake 'em all, but not sure how popular/complete they are.

scottschulthess 14y ago
Well I think it depends, sqlite can behave as an entirely in-memory database I think - so what would be the difference between that and a pure ruby in-memory database, really? If you want to just fake 'em all, which does not sound particularly ideal, people just generally mock em
- edwinnathaniel 14y ago
  Yes, my bad for not clarify it: mock the repository part, but not to mock as an entire ActiveRecord. for example: FriendsRepository.java is an interface that can be mocked during unit-test while the integration-test would use the actual implementation. I know that the Java solution tend to be brittle because it somewhat forces people to have 1 interface, 1 class implementation (the mock implementation would be provided by mocking library).

cirwin 14y ago

It's very similar you're correct, particularly when you add in the Manager/Service layer (something that I hadn't spent enough time investigating). The main advantage of Operations over controllers is that they're fully composable. You can take the operation that logs a user in (which displays the login screen, and awaits the user typing a username and password) and use it as a sub-part of any other operation. In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. I'll certainly be following up with more details, and some actual code.

scrame 14y ago
Right, but in an MVC web-app, the Controller defines the "end-point". Meaning it should end there. The composition of different pieces of functionality should be happening in the area of the business logic. I understand the motivation, and have come across several situations where I wanted "controllers calling controllers", but ultimately, you're repurposing a piece of the architecture to do something it shouldn't be doing. A controller handles the input into the system, it shouldn't be defining a workflow. > In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. That just sounds backwards to me. Are talking about creating dynamic endpoints? That sounds like a much bigger headache than composing stuff in a service layer. MVC can be a little ambiguous, and with web-frameworks it can be hard to see that each piece is actually a subsystem. The Model isn't just your model class, its the model class, the DB and the ORM library you are running. Similarly, the View is the entire response / template rendering subsystem. The part that is addressed in the framework is mostly the "controller" subsystem, which is a way of organizing code so that the actual "controllers" can do the primary work of sanitizing input, delegating function calls and returning the output to the View system. Again, MVC is just a pattern that doesn't fit perfectly in the web request/response cycle, which then necessitates a pattern to handle the leakage (in my case I'm talking about the service/manager pattern). However, I just don't see your suggestions that MVC is "dead", or how this system is radically different. It seems like it is just semantics.
14y ago

kreek 14y ago

This looks like MVC to me as well, except what MOVE is calling operations I would call commands. There are quite a few MVC frameworks that work like this, including PureMVC which has been implemented in almost every OOP language http://puremvc.org/ http://puremvc.org/.

calinet6 14y ago

Yep. It's MVC with eventing (often found in most UI frameworks anyway). Definitely fits within the broad paradigm of MVC.