optional · CSS study notes
6. Software Architecture, Styles, Patterns & Frameworks
CSS Optional — Paper-II, Section-B · P-II.VI.6 · The conceptual base for all web architecture topics. Expect "differentiate style, pattern and framework" or "explain MVC".
1. Software Architecture
- Definition (Bass, Clements & Kazman): the set of structures needed to reason about a system — software elements, their externally visible properties, and the relations among them.
- In short: the high-level organization of a system — its major components and how they communicate.
- Why it matters: it fixes quality attributes (performance, scalability, security, maintainability) early; it is the hardest thing to change later; it enables team communication and reuse.
- Architectural decisions in web apps: where logic runs (client vs server), how many tiers, synchronous vs asynchronous communication, how data is stored and cached.
2. Architectural Styles
A style is a family of architectures sharing a vocabulary of components/connectors and constraints on how they combine.
| Style | Idea | Strength | Weakness | Web example |
|---|---|---|---|---|
| Layered | Each layer serves the one above | Separation of concerns, replaceable layers | Performance overhead passing through layers | Presentation / business / data layers |
| Client-server | Clients request, server provides | Centralized data and control | Server bottleneck / single point of failure | Browser ↔ web server |
| Pipe-and-filter | Data flows through independent processing steps | Reusable, easy to reorder filters | Not for interactive systems | Image upload pipeline: resize → compress → watermark |
| Event-driven / publish-subscribe | Components react to events via a broker | Loose coupling, scalability | Harder to trace/debug | Order placed → email, stock and analytics services react |
| Repository / data-centred | Components share a central data store | Consistent shared data | Store becomes bottleneck | CMS with a central content database |
| Service-oriented (SOA) | Business functions as reusable services on a bus | Integration of heterogeneous systems | Heavy middleware (ESB) | Enterprise web services |
| Microservices | Small, independently deployable services with own data | Independent scaling and deployment | Operational complexity, network latency | Netflix, large e-commerce |
| REST | Stateless client-server over resources with uniform interface | Simple, cacheable, scalable | Chattiness for complex queries | Public web APIs |
| Peer-to-peer | Nodes are both clients and servers | No central point of failure | Security, consistency | BitTorrent, WebRTC calls |
3. Patterns
- An architectural pattern is a proven, reusable solution to a recurring system-level problem in a context (e.g. MVC). A design pattern solves a recurring problem at class/object level (Gang of Four, 1994: 23 patterns in creational, structural, behavioural groups).
MVC — Model-View-Controller (the key web pattern)
graph LR
U["User / browser"] -->|"request"| C["Controller"]
C -->|"updates / queries"| M["Model: data + business rules"]
M -->|"data"| C
C -->|"selects"| V["View: HTML template"]
V -->|"response"| U
- Model: data and business logic (e.g. Student, Course, fee rules). View: presentation (templates). Controller: handles input, calls model, chooses view.
- Benefits: separation of concerns; parallel work (designers on views, developers on models); multiple views of the same model (web and mobile); easier testing and maintenance.
- Used by Laravel, Django (as MTV), Ruby on Rails, ASP.NET MVC, Spring MVC, Struts.
Other web-relevant patterns
- Front Controller: one entry point handles all requests (Struts ActionServlet, Laravel's index.php).
- Page Controller: one controller per page (classic PHP pages).
- Template View: HTML with embedded markers (Blade, JSP).
- DAO / Repository: isolate database access.
- Singleton (one DB connection pool), Factory, Observer (event listeners), Facade, Proxy/Cache.
4. Frameworks
- A framework is a reusable, semi-complete application that provides structure; you fill in application-specific parts. It implements styles and patterns in code.
- Inversion of control ("Hollywood principle: don't call us, we'll call you"): the framework calls your code, not the other way round.
| Point | Library | Framework |
|---|---|---|
| Control | Your code calls the library | Framework calls your code (IoC) |
| Scope | Specific task (e.g. dates, charts) | Whole application skeleton |
| Example | jQuery, Lodash, React (a UI library) | Laravel, Django, Spring, Angular, Struts |
Web frameworks by language: PHP — Laravel, Symfony, CodeIgniter; Java — Spring, Struts, JSF; Python — Django, Flask; JavaScript — Express, Next.js, Angular, Vue; Ruby — Rails; C# — ASP.NET Core.
5. Style vs Pattern vs Framework
| Concept | Level | Form | Example |
|---|---|---|---|
| Architectural style | Whole system, most abstract | Vocabulary + constraints | Layered, client-server, REST |
| Pattern | Recurring problem, concrete solution idea | Documented solution template | MVC, Front Controller, Singleton |
| Framework | Implementation | Actual reusable code | Laravel implements MVC + Front Controller |
🎯 CSS Exam Angle
Define architecture, then use the style → pattern → framework ladder with one web example at each level. Draw MVC — almost every architecture question can use it. The library vs framework table is a quick, well-rewarded addition.
⚠️ MCQ Traps
- MVC is a pattern, not a style or framework; Laravel is a framework.
- Inversion of control distinguishes frameworks from libraries.
- In MVC the Model contains business logic, not just data.
- REST is an architectural style (Fielding, 2000), not a protocol.
- GoF patterns are design (class-level) patterns.
✅ Self-Check (with Answers)
Q1. Define software architecture.
Ans: The high-level structure of a system: its major software elements, their externally visible properties and the relationships among them. It determines quality attributes and is costly to change later.
Q2. Which style suits an image-processing upload service and why?
Ans: Pipe-and-filter: the image flows through independent steps (validate → resize → compress → watermark → store), each reusable and replaceable.
Q3. Explain the responsibilities of each MVC component with an e-commerce example.
Ans: Model — Product and Order classes with pricing and stock rules; View — product-listing and cart HTML templates; Controller — receives "add to cart" request, updates the Order model, returns the cart view.
Q4. Differentiate a library from a framework.
Ans: Your code calls a library for specific tasks; a framework provides the application skeleton and calls your code (inversion of control). E.g. jQuery (library) vs Laravel (framework).
Q5. Give two advantages and one disadvantage of microservices.
Ans: Advantages: services scale and deploy independently; teams can use different technologies. Disadvantage: operational complexity — network calls, distributed data consistency, monitoring many services.