4 ms·

MVC framework is just a delivery mechanism and your business logic should be outside of it. Your business logic should have no idea about web, console, controll

• why-el 14y ago
  Do you know of a highly successful startup or company doing this? i.e. Same logic with different delivery mechanisms and no hassles whatsoever?
• virmundi 14y ago
  I tend to find this dream rather fevered. A controller knows about the model. It knows about the view. It acts as a conduit between itself, the view and model. In the web, the models are not really event based. Some platforms have tried this, but it tends to not work out well at scale. So ultimately the controller tends to get a lot of business logic embedded because it's difficult to put that logic somewhere else. The problem with this is that the controllers are very much view-centric. Take .NET for example. There are forms. Logically this is the controller. Events happen, handlers manipulate domain objects and create responses, the result goes to the view. The problem is that even .NET makes a divide between WinForms and WebForms. Entirely different namespaces. Thus your controller is view bound and blocked. Now you might want to push the logic from the controllers down into the domain objects. This is fine. But, as other talked about with testing, you will have to make sure that you're not doing too much with your domain objects. So you'll probably start to use interfaces and constructors for the domain objects to abstract away view details. You might even use callbacks (another type of interface). So you're feeling pretty good now. But eventually this type of configuration become heavy. It also might not mesh with your system. I'm not sure about Rails, but Hibernate makes is rather hard to IoC objects it makes. It's really hard to do that by having Spring create your instance variables returned by Hibernate. In the end, the difficulty of making domain objects smart and loosely coupled, but still coupled to other components while using an ORM makes the whole attempt for naught. Thus you will circle back and put the business logic in the controller or some controller adjacent code that is closely coupled with the view.
  • mattgreenrocks 14y ago
    The whole point of attempting this is to allow these difficulties to force you to decompose the system further than you would using the larger building blocks of MVC. About six months into working with Rails full time, I began wanting a third place for my logic. Controllers were suboptimal, and models weren't always right. Coming from a native apps, I felt restricted. I later learned that POROs were well and good. But I doubted myself because the Rails way says little.
    • virmundi 14y ago
      I'm good with POROs (assuming Plain Old Ruby Objects). I'm a huge fan of Domain Driven Design. My issue with the parents is that without going into what many Rubyists would call Java-land, one would find it hard to separate concerns. Also, I don't agree that an MVC can truly be fully decoupled from the V. This is why one seldom has one MVC to rule them all.
  • freework 14y ago
    Take a look at giotto, a python web framework that tries to do exactly what you're proposing: separation of model, view, and controller so that they are completely decoupled: https://github.com/priestc/giotto https://github.com/priestc/giotto
• programminggeek 14y ago
  I agree. I based the Obvious Architecture around Uncle Bob's blog posts Clean Architecture and Screaming Architecture. It's taken months of testing, building and thought, but I think it's come out pretty nice on the other side. Both the delivery mechanism and the external persistence mechanisms are separate and pluggable from the app code itself. You can go in the app/ directory of a project and read the file names of your actions and entities and know right away what the system does. Testing is fast because it never hits a database. Test doubles and mocking are easy to build and don't require a 3rd party lib. Data traveling between the app and the external systems is validated via contracts. It ends up being the most enjoyable TDD experience I've ever had. For example, last night I put together an example "twitter" status update app in obvious. I got all the entities, actions, and contracts written TDD in about 3 hours. Today I'll be adding a delivery mechanism and probably filesystem and mysql plugs. Would be easy to write an api or console app and plugs for mongo, postgres, or whatever. Code is here: http://github.com/RetroMocha/obvious_status http://github.com/RetroMocha/obvious_status