Hyves laat politie inval doen bij makers Hyvesbot

By the way, er is geen Service layer in een MVC. Het is nog steeds Model, View en Controller. Strikt gezien vraagt of kijkt de view helemaal nergens naar, maar abonneert de view zich aan het Model. Verandert er iets in het Model, dan krijgt de View...

Het is niet zo eenduidig en er zijn meerdere implementaties mogelijk. Ten eerste kan m.b.t. de View zowel het push model als het pull model ondersteunt worden. D.w.z., dingen worden naar de view gepushed, of de view pulled het zelf binnen. Er zit daarnaast al een wereld van verschil tussen een klassieke MVC implementatie op de desktop en een request/response gebaseerde implementatie zoals in een web omgeving.

Dan je opmerking over de service layer. De M in MVC staat idd voor Model. Het is niet MVS natuurlijk. Echter, je model bestaat uit... je model objecten. Dat zijn data models of te wel business entities. (als in Class Customer { Long id, String name, ... }. Hoe gaat je controller aan instances van deze model classes komen? Hoe gaat je controller om met high level commando's die op deze model classes van toepassing zijn?

Als je alleen direct 1:1 aan model instances wilt komen (voor CRUD achtige operaties), voldoet het DAO pattern uitstekend. Je hebt dan weliswaar je applicatie abstract opgedeeld in een View, Control en Model gedeelte, maar de concrete toegang via je model gaat via DAO's. High level operaties, waarbij meerdere model classes betrokken zijn, abstraheer je dan weer veel beter via services. B.v. iets als registerCustomer, wat als commando vanaf je view wordt aangeroepen, kan via de controller het beste worden doorgestuurd naar een service die dan op verzoek van die controller een 'task flow' af loopt die meerdere model classes beinvloed en operaties uitvoert zoals het verzenden van welkomst emailtjes.

In een EJB applicatie met een remote client is dit nog veel duidelijker. Je view wordt dan geimplementeerd door Swing widgets. Je controller bevind zich ook grotendeels in je Swing applicatie, en koppelt aan je view via o.a. event listeners, terwijl toegang naar je model via (stateless) session beans gaat, die een service implementeren.

Je kunt beargumenteren dat de service dan enige controller taken over neemt. Met een statefull session bean (nog steeds een service) kun je de "task flow" grotendeels op je swing client houden.

In deze opzet zie je een hele duidelijke scheiding tussen view logica en de logica die je model aanpast. De service API wordt vrij onafhankelijk geschreven en kan door hele andere programmeurs gemaakt worden dan die die de Swing client schrijven. Als je uitgaande van deze opzet nu de Swing client vervangt door een JSF front-end, dan heb je alleen een andere client toegevoegd aan je systeem. Ook deze JSF client kan weer door een geheel ander team worden geschreven.

Een brakke implementatie van oftewel de JSF client, oftwel de Swing client, hoeft niet meteen te betekenen dat de Service layer en het onderliggende data model brak is.