4 ms·

SOA (Service-oriented architecture) is a pattern to split an application into discrete pieces of software providing application functionality as services to oth

SOA (Service-oriented architecture) is a pattern to split an application into discrete pieces of software providing application functionality as services to other applications. Fat vs Thin is more over a debate about where to place logic. Thin implies controllers are small, and models have a wider responsibility. Fat is the inverse, where controller do the majority of work, and models are a small abstraction. My point is this: They are not the same thing. SOA helps in designing scalable, robust systems. Fat vs Thin helps you decide where logic should go. I'm proponent of SO design and thin controllers.

PaulHoule 13y ago
Well, unless you design them for high performance from the very beginning, SOA also helps in building slow systems that your customers will hate and that will fail in the marketplace if the people who buy the software actually use it. (I was at Altassian's San Francisco office a few months ago and I said half-jokingly that I quit my last job because I couldn't stand waiting for Confluence, and all the other off-brand webapps my employer used, to load.) Now I use Github, which offers true interactive performance even over crappy DSL connections. I'm not going to work for anybody who makes me use some off-brand webapp that makes me wait 30 seconds to put time on a ticket or to edit a Wiki page. SOA can be part of the solution rather than the problem, but it takes a clear architectural view from day one and a commitment to avoid stupid and obvious mistakes, as the article points out.
- Gigablah 13y ago
  Not sure why you're blaming SOA there. Atlassian apps are standalone instances so, assuming your former employer self-hosts, it has more to do with your own server and network performance. In fact GitHub is most likely closer to SOA architecture than Confluence is.
  - PaulHoule 13y ago
    They weren't self-hosting. And whether it is SOA or not, the moral is that many many systems are designed and sold as if performance didn't matter. I had another job where the team toiled for years to develop an SOA system that, when we first stacked it all up, took 45 minutes to boot up an RIA because it did 50,000 requests to initialize it's state. Sure, this is stupid design, but people do this all the time. I was able to speed the boot time to 20 seconds by packing much of the data with the application file and creating one "initialize" call that downloaded all of the data necessary to initialize a particular instance of he app in one shot. Had performance been built into the app from day one that app might have seen the light of day.
Jormundir 13y ago
Fat vs. Thin does not apply to a specific topic. Fat vs. Thin can apply to controllers and models, but that's an exhausted argument, in models code is more reusable, fat controllers are, in my experience, the most obvious symptom of not understanding DRY principles and of not having good conventions and architecture. In the client-server realm, fat vs. thin is about how much code to run on the client side, i.e. how much javascript to deliver, how much of the UI is handled by the client before the server is bothered. You can have a thin server with fat controller methods, or vice-versa. The point is the fat vs. thin battle happens in a lot of different areas, not just controllers.

PaulHoule 13y ago

Well, unless you design them for high performance from the very beginning, SOA also helps in building slow systems that your customers will hate and that will fail in the marketplace if the people who buy the software actually use it. (I was at Altassian's San Francisco office a few months ago and I said half-jokingly that I quit my last job because I couldn't stand waiting for Confluence, and all the other off-brand webapps my employer used, to load.) Now I use Github, which offers true interactive performance even over crappy DSL connections. I'm not going to work for anybody who makes me use some off-brand webapp that makes me wait 30 seconds to put time on a ticket or to edit a Wiki page. SOA can be part of the solution rather than the problem, but it takes a clear architectural view from day one and a commitment to avoid stupid and obvious mistakes, as the article points out.

Gigablah 13y ago
Not sure why you're blaming SOA there. Atlassian apps are standalone instances so, assuming your former employer self-hosts, it has more to do with your own server and network performance. In fact GitHub is most likely closer to SOA architecture than Confluence is.
- PaulHoule 13y ago
  They weren't self-hosting. And whether it is SOA or not, the moral is that many many systems are designed and sold as if performance didn't matter. I had another job where the team toiled for years to develop an SOA system that, when we first stacked it all up, took 45 minutes to boot up an RIA because it did 50,000 requests to initialize it's state. Sure, this is stupid design, but people do this all the time. I was able to speed the boot time to 20 seconds by packing much of the data with the application file and creating one "initialize" call that downloaded all of the data necessary to initialize a particular instance of he app in one shot. Had performance been built into the app from day one that app might have seen the light of day.

Jormundir 13y ago

Fat vs. Thin does not apply to a specific topic. Fat vs. Thin can apply to controllers and models, but that's an exhausted argument, in models code is more reusable, fat controllers are, in my experience, the most obvious symptom of not understanding DRY principles and of not having good conventions and architecture. In the client-server realm, fat vs. thin is about how much code to run on the client side, i.e. how much javascript to deliver, how much of the UI is handled by the client before the server is bothered. You can have a thin server with fat controller methods, or vice-versa. The point is the fat vs. thin battle happens in a lot of different areas, not just controllers.