I know service classes aren't strictly part of the MVC pattern but I thought the following would make more sense with a reference to MVC, or application frameworks in general.

Am I correct in thinking that a service class, while commonly associated with network services using SOAP etc, isn't required [by design] to access a network service? In other words, could a service class used within an application framework access a local file system or a FTP server?

[Nutrox]

Argh, there be no replies 'ere, ye scurvy dogs! I be assumin' services can do whatever they be needin' to do.

[Isocase]

Sorry Nutrox but I haven't moved into the MVC world completely yet so I am of no help.

[Codemonkey]

Correct, a service is not required to access a network.

That is, assuming in this case you are talking about a service layer with an integrated DAO layer (in your case services define business logic as well as logic to retrieve remote data). This is a common approach in non-corporate level flash applications.

If you are using some sort of DAO layer separate from the service layer, then the service doesn't access anything; it just defines business logic. In this scenario a DAO object encapsulates the logic for fetching remote data -be it by means of a network, file access, or anything else- and the service(s) hold a reference to a DAO instance.



In Cairngorm however, the Business Delegates (or commands) have the function of DAO's, on the lowest level within the (Flash) application. The services here are depicted as being physically in a another server, which ofcourse doesn't have to be the case, just think of locally accessing an XML file. The use of these terms in varying diagrams may be confusing.

[Nutrox]

Thanks for reply Codemonkey.

So, just to get this clear in my head, if I did have a Service layer and a DAO layer the job of the services would be to handle DTO(VO) conversion, and the job of the DAOs would be to access a network or file system etc in order to send/receive the raw data?

View > Controller > Command* > Service* > DAO > Service* > Command* > Model > View

[Nutrox]

I think it has finally clicked. I could have a LoginService and a NewsService, both of which use the same DatabaseDAO to access the information they require.

request.username = "foo"
request.password = "bob"

loginService.send( request )

request.channel = "science"
request.total = 10
request.order = "ascending"

newsService.send( request )

The services would (ideally) return the information as a DTO, so I might have a NewsListDTO containing a load of NewsItemDTO objects.

Makes sense.

[Codemonkey]

You got it.

[Nutrox]

Codemonkey, what are beans and how do they fit into an application framework? I keep seeing terms such as "entity bean" and "session bean" - they sound like DTOs with built-in DAO logic.

[Codemonkey]

Entity and session beans are something from the Java world, and then one from a sub culture (EJB). Just ignore their specifics, these beans don't apply to Java in general nor to Flash applications.

In short, an entity bean is a domain specific object like an Order, or Customer, which you can persist directly into a database. An entity bean for example can hold an id as well. You are right that these entity beans sound like dto's with built-in dao logic, which is what so called 'bean-managed' beans do (there's also 'container-managed' beans).

A session bean is a bean specific to a single user's session, like when you go to a website that is powered by Java (and then EJB, the sub culture), the server creates session-scoped beans which are used for your visit to store your submitted/retrieved data.

I have to admit though that EJB is not really my territory, I've used Spring alternatives instead...

FYI, there is also the general JavaBean specification, which states that a bean is an object with no logic at all, just a container for information, which setters and getters for each piece of information it can hold. It furthermore specifies how the getters should be named, which basically amounts to booleans: isCustomerValid() and any other datatype: getCustomerName(). Notice the prefix 'is' and 'get'. These kind of beans don't apply to entity beans, but I think they might apply to session beans. JavaBeans allow for consisten automated processing of java objects (with reflection for example) and predictable behavior.

[Nutrox]

Thanks man, you've been a huge help.

[Nutrox]

Just need to check something quickly: If I need to use a service for getting and setting data, would I use specific request classes such as GetAccountRequest SetAccountRequest, would I hint at the data direction with methods service.send(request) service.load(request), or would the actual request object hint at the data direction request.mode="read" request.mode="write" ?

I'm being attracted to specific GetAccountRequest SetAccountRequest classes for some reason.

[Codemonkey]

I'm not sure what you mean by account request classes, but you could call methods on your service to get some calculation going (business logic) and if it needs data from some server it would just ask the dao for that data.

Data direction, if you want to name it, is indeed with simple send methods but not so much in that sense. For example, if you want to store a Customer in your database, you could say:

// in controller or command or whatever
service.saveCustomer(customerObject OR any collection of parameters that form a Customer);
 
// in service:
validateInput(customerObject OR any collection of parameters that form a Customer);
var customer = new Customer(any collection of parameters that form a Customer);
customer.setModificationDate(new Date());
customerDao.save(customer);
 
// in dao
var dbClient:XMLSocket = new XMLSocket();
dbClient.sendPersistCustomerRequestBlahBlah(customer); 

The controller is not concerned with sending/receive requests, it is concerned with finding and storing domain objects. Only slightly different way of thinking that is.

Hope that helps.

[Nutrox]

Thanks, that will be the last technical question for a while hopefully.

If you have the time could you let me know what you think about the following idea:

I have noticed that a View will occasionally need to know when a Command has fully executed or will need to be informed of low level application activity that doesn't warrant the use of a Model. One thing I really don't like is when a framework allows a Command to access a View's API directly, it just seems to go against the grain of the underlying MVC pattern, so I was thinking about introducing a very simple application-specific messaging system. What I have in mind is similar to the AS3 event model but the Application object is the only message broadcaster and exposes a public broadcastMessage() method, any objects (i.e. Views) that need to listen for messages can register a callback with the Application. The messages are identified by integers instead of events/strings.

Application.api.addMessageReceiver( receiver );

function receiver( messageID:uint ):void
{
    if( messageID == Messages.USER_PROFILE_SAVED )
    {
        enableSaveProfileButton();
    }
}

Application.api.broadcastMessage( Messages.USER_PROFILE_SAVED );

I quite like the idea of that but how does it sound to you, can you think of any problems it could cause?

[Codemonkey]

I don't see any problems at all with this approach, because you actually are creating a model with listening views: you're using the global api object as a stateless model that can broadcast state changes caused not by model changes but by Command completions.

You just don't keep track of the particular state in the api model and called it an application-specific messaging system. If it helps you structure/manage your application better, it's all good.