What's in application layer? Answers from googling springframework

SpringNET

http://www.springframework.net/docs/1.2.0/api/net-2.0/html/topic8617.html

The application layer your web form communicates with is where the business logic resides, not in the web tier.

..., leading ideally to an event-handler that does not contain any reference to UI elements.

... the conversion of HTML control data to object and then vice-versa ... by the application layer.

... the data model that you build up to submit to the application layer.

 

http://www.springframework.net/doc-1.1-P3/reference/html/transaction.html

A simple data access layer would be not much more than data access objects (DAOs) which 'Create/Retrieve/Update/Delete' (CRUD) methods devoid of any business logic. Business logic resides in another application layer, the business service layer, in which business logic will call one or more DAOs to fulfill a higher level end-user function.

 

http://forum.springframework.net/showthread.php?t=4159

This is possible with NHibernate, as a Session will keep the underlying ADO connection open from first query until it is closed, and transactions are optional. Spring's DAL uses a SessionScope to abstract this from the application layer.

 

http://forum.springframework.net/showthread.php?p=5118

As document says, i should be able to use Validation Framework from any application layer.

 

Spring

http://jira.springframework.org/browse/SWF-691

There are minor differences in the application layer code between the MVC and Faces versions of the booking samples.

In detail, the SearchCriteria differs (setPage(int) versus nextPage(), resetPage(), previousPage()) and the Service differs (MVC has cancelBooking(long) versus cancelBooking(Booking)).

This indicate that application layer consists at least controllers.

http://forum.springframework.org/showthread.php?t=24518

 WEB N-TIER
Presentation <-> Application + Business + Mapping <-> Persistence
where
Presentation = Browser + Web Server + Web Framework + Dynamic Pages + View Controllers
Application = Command + Undo/Redo/Command History
Business = Domain Model
Mapping = O/R Mapping
Persistence = RDB

DESKTOP 2-TIER
Presentation + Application + Business + Mapping <-> Persistence
Presentation = Swing + Views + View Controllers
Application = Command + Undo/Redo/Command History
Busienss = Domain Model
Mapping = O/R Mapping
Persistence = RDB

I hope to make the View Controllers in the Web and Desktop Apps share a similar interface so that the Application layer (Command + Undo/Redo) can be generic (i.e. not Web or desktop specific).

This is in contrary of the above one. Application layer are considered to be Commands and controllers are not in app layer.

We have done our DTO (Btw. we call it ViewBeans in our Project) to Domain Object transformation in the application layer (which exists between the presentation and the domain layer).

The methods on the application layer are called with the DTOs as paramters,
and after doing the mapping there they will call the services on the domain layer itself. 

Contrary

Unless there is some reason to decouple application layer from the domain layer, like specific needs of remoting, I would do away with the DTOs and encourage usage of domain objects throughout. That way, you reduce the number of classes, get rid of behaviorless transfer objects and foster stronger domain model usage across the application layers.

http://forum.springframework.org/showthread.php?t=61488

your application handles the Presentation/Application layer such user sessions, page flows, rendering pages. It also handles the business rules within the domain layer + transactions + making calls to the database + handling concurrency, etc.

so called "Service Layer":

org.myapp.application

This is where all of the UI coding goes in here, such as controllers for web apps. Swing and console app implementations can also go in here.

org.myapp.service

This encapsulates the business rules, acting as a Facade - meaning that changes can be made to the code with minimal interruptions (i.e. your web page is unaffected by certain changes to bus rules). No bus rules here.

org.myapp.domain or org.myapp.model

In answer to your question, domain classes goes in here. This is where the business rules are kept. DTOs are also placed here primarily used for communicating between the Application and Domain layers and protecting your Entities and business rules. It also suplements the Service layer in protecting the application from code changes.

You can also make calls to a data source here as well, if you're deciding on a Template Pattern approach.

(optional) org.myapp.dao

To simplify the Domain/Model layer further, you can implement calls to the data source here and use the Strategy Pattern.

Exactly as my confusion, see below:

I think you both got screwed by diffrent layer patterns.

The most simple layer pattern is like:

persistence layer <--> domain layer <---> presentation layer

The persistence layer is about durability (how things get stored, database, filesystem etc.)
The domain layer contains all business and model parts.
The presenstation layer is about the interface to any user (wether biological systems (human, animals) or electronic systems (computer, reactive switches etc.))

So to state your question clear, business+model is domain. What you like to refer to seams like a seperation between business and model and when to move business logic to model elements (like entities) and when to move the logic to business services.

This is one of my question. But sometimes there is an extra layer introduced between the data layer and the presentation layer: the application layer:


The stack of layers.


presentation layer
---------------------
application layer (also the boundary for transactions and security)
---------------------
domain layer
---------------------
persitance layer.
---------------------

The application layer (sometimes called the service layer/application layer I believe) is the boundary for transactions and security and also contains logic like sending email of and jms if something should be reported.

I already wanted to integrate the application layer and the domain layer to a single layer.. I have more to do than writing empty classes.

Well this is quite difficult to answer, but may be quite simple, too. One idea is to never rely on the value object pattern, when shaping entity (or model elements).

How do you mean?

Move allways as much logic (business logic) to the domain elements (entities) as you can. There are two distinction to this advise. First, the business logic is a suject of change (like policies etc -> rulebased business logic) and second, if the business logic requires a broader scope. Mostly a domain element /entity should not fiddle with transactions by itself, nor should it incooperate with elements from distant model parts (like a Person object negotiating with a traffic light object) or the business logic envolves extense operations on a variety of objects (extense sql-statements for example).

So if it is about an object (setName, setParent, addChild, calculateTax) put it into the domain element, if it is about a collection of objects put it into the DAO (if it is related to the same kind of object) or put it into some business service objects if it is based on extens intercooperation between objects of various kind.

Should a domain object have a reference to dao`s? THe layer on top could coordinate the transactions (I`m not afraid of this). But how (or if) should a domain object get a reference to a dao?

Thanks for the information so far. I`m feeling a littlebit lost.. and I don`t like that.

 

 

 

 

 

 

 

It seems that, application layer is still not very clear to me. Continue searching...