In web project can we write core services layer without knowledge of UI ?

Question

I am working on web project. We are using flex as UI layer. My question is often we are writing core service layer separately from web/UI layer so we can reuse same services for different UI layer/technology. So practically is it possible to reuse same core layer services without any changes/addition in API with different kind of UI technologies/layers. For e.g. same core service layer with UI technology which supports synchronized request response (e.g. jsp etc.) and non synchronize or event driven UI technology (e.g Ajax, Flex, GWT etc.) or with multiple devices like (computers, mobiles, pdas etc.). Personally I feel its very tough to write core service layer without any knowledge of UI. Looking for thoughts from other people.

Answer 1

It shouldn't be difficult to write core services without knowledge of the UI at all.

The core services just need to know what data is needed to perform their tasks (where it comes from doesn't matter).

Once you have the core services designed, you can then build several different UIs on top of them that collect the necessary data and pass it to the services...which would then perform their specific duties.

Answer 2

It is possible of course. Services layer is most often stateless, so it just offers methods to be called with parameters that come from the UI. You can imagine it as an API that you call from your UI layers. It is important not to pass anything UI-related as a parameter. For example, don't pass HttpServletRequest or HttpSession as parameters - obtain the values needed and pass them.

Answer 3

My question is often we are writing core service layer separately from web/UI layer so we can reuse same services for different UI layer/technology

The service layer should be agnostic of the UI, so that's actually very good.

For e.g. same core service layer with UI technology which supports synchronized request response (e.g. jsp etc.) and non synchronize or event driven UI technology (e.g Ajax, Flex, GWT etc.) or with multiple devices like (computers, mobiles, pdas etc.).

A business operation exposed in a service layer should theoretically not depend on who calls it and which technology. But you seem to be facing to common symptoms:

1. different UI do actually require slightly different business operations (e.g. the amount of data returned may differ for mobile and non-mobile caller)
2. the business operations is coupled with the remoting technology (e.g. synchronous vs. asynchronous)

For 1. the question you must ask yourself is whether you can factor these slightly different operations elegantly, or the opposite, how to expose variations of the same operations elegantly. In both cases, it should be possible to design a service API that is consistent and fit the need of various clients.

For 2. the question you must ask yourself is how to decouple the business operations from the remoting technologies. A bridge or adapter or an extra mediation layer could be introduced, but that should not lead to over-engineering.

I know it's sometimes hard to decouple the business operation completely from its actual usage. Let's consider pagination: if the business operation is "I want data for query X", the concrete operation exposed does also embed some knowledge of the UI, namely the paging.

I can only provide a general advice: fight for a clear separation between UI and business when it comes to data, formatting, etc. and when you can't, try to figure out the most generic API that makes sense for all clients.

Personally I feel its very tough to write core service layer without any knowledge of UI.

I agree it's hard sometimes, but you seem to be doing it right -- so continue this way :)