You now have everything you need to implement SOOJS into any of your current or future projects. The organization of when to separate elements is the only real decision that remains.

MVC helps us here. I won’t go very deeply into this, but it’s simple to say that you will be best served if you try to very clearly separate the UI from the business logic and control of the system. And that sounds so simple. But a given rule like “show dates in local format” can give you fits to determine if it should be part of the logic of the controller or an implementation detail to the view. Those debates will continue forever.

For the time being let me emphasize a few components that are found in most every program.

  • Controllers (logic)
  • Controllers (view)
  • Connectors
  • Objects / Structures


This is not strictly a part of SOOJS, but is helps create the environment for a clearly defined SOOJS project.

I find it helpful to create controllers, and view controllers. They are really the same object, but I can clearly understand their rolls when I see a directory of “view controllers”. I know they are the UI implementation. Also, I know that if I’m in a controller or connector, or even an object and I’m trying to update the UI I know it’s the wrong place. It is likely the easiest place to have a bit of code in the “Item” class to update the checkmark when its own isComplete boolean is changed. But this is not about the easiest path. That is exactly how poorly constructed, expensive to maintain, ridden with bug applications are born. You have to be diligent about this yourself.

In the TodoMVC example project the files layout looks like the following:


From that image you can see the common layout I use for smaller projects. Of note is the ItemCollection (an array, essentially) that is in the controllers directory.


As you can see from the requests object these are the many things this collection does over and above what a standard array does.

Note: I very commonly code and organize so that my source can be collapsed in a meaningful way. It’s another benefit of having internal objects separating the parts.

The last item I will mention here is that of Connectors. Connectors are slices of code that call off-system in any way. They encapsulate the interactions cleanly and can very easily be tested when separated. It’s also very easy to use a different connector, or dummy up (stub) interactions when the connector itself is stand-alone. And finally, as one of the more delicate parts of an application you want to be able to lock changes to connectors whenever possible to prevent accidental changes to API implementations.

And when I say off-system, I really mean anything that is not core to the code you are writing. It could be a web service, or another piece of JavaScript written by another team that you simply implement. Very commonly they deal with data-in or data-out.

Series Navigation<< The Delegate PatternSOOJS Examples >>