[RESOLVIDO] Spring: interface para DAO é realmente necessário?

Estou começando com o framework Spring. Nos diversos exemplos q vi para DAO, como por exemplo este, são utilizadas interfaces para cada classe. Testando aqui vi q funciona sem as interfaces. Buscando deixar o código o mais simples possível, teria algum problema não utilizar as interfaces?

Obrigado,
Felipe

[quote=FkJ] Buscando deixar o código o mais simples possível, teria algum problema não utilizar as interfaces?

Obrigado,
Felipe[/quote]

Em um desenvolvimento orientado a Aspecto ou Objeto ?

Esqueça Marcio Duran, usar interfaces não difere se a sua decisão é usar ou não aspectos.

É o seguinte: dá pra não usar interfaces, mas o risco é que você não consegue mais desacoplar as classes, sem mexer no código. Usando interface, um bean pode ser declarado usando qualquer classe que implemente ela. E isso deixa seu sistema mais flexível.

de repente é por causa da questão do acoplamento fraco que ele pergunto isso…é uma caracteristica de OO…

segundo a Kathy no livro preparatório do scjp, a classe que instancia um objeto saber apenas os dados do contrato, isto é, da interface em

List lista = new ArrayList();

como um exemplo, é um fato caracteristico de acoplamento fraco…

vc não precisa disso, mais é aconselhavel…

obs. eu to falando de OO não de spring, q eu não conheço, mais é obvio que se encaixa no assunto

[quote=FkJ]Estou começando com o framework Spring. Nos diversos exemplos q vi para DAO, como por exemplo este, são utilizadas interfaces para cada classe. Testando aqui vi q funciona sem as interfaces. Buscando deixar o código o mais simples possível, teria algum problema não utilizar as interfaces?
[/quote]

Não importa que funciona. Vc não usa OO para que os sistemas funcionem ( procedural tb funciona).

O principio de encapsulamento adverte que vc não deve deixar objetos de outras classes acessarem ou terem conhecimento do acontece dentro da classe. Para fazer isto a for mais simples é criar uma interface e implementação separada.

Por outro lado o DAO é um serviço, ou seja, é uma classe cujo proposito fundamental é fazer algo por vc ( no caso , persistir objetos)
Mas a forma como isso pode ser conseguido não é fixa. Várias implementações são possíveis para uma mesma interface.

É por isto que o DAO é definido como uma interface e uma ou mais implementações.

ao contrário do que pode parecer usar interfaces é mais simples que usar classes.

Podemos abstrair a seguinte caracteristica, para o Spring.

br.com.jm.springjsf - Contém a classe Xcontato, utilizada como o objeto de domínio.
br.com.jm.springjsf.form - Contém o managed bean utilizado pelo JSF dentro da aplicação
br.com.jm.springfsf.facade - inclui a classe que representa o Façade utilizada na aplicação.(lógica de negócios), fazemos apenas delegação de acesso a dados à layer tier data e controle transacional.
br.com.jm.springfsf.dao - Classes e interfaces da camada acesso a dados.Essas classes se apóiam em recursos do Spring para facilitar o acesso a dados.

“Para quem não quer falar muito, o Spring utiliza a orientação a aspectos para fazer o controle de transações”

[quote=FkJ]
Buscando deixar o código o mais simples possível, teria algum problema não utilizar as interfaces?

Obrigado,
Felipe[/quote]

Ola Felipe,

E importante sim utilizar interfaces, porque o Spring ira Injetar(DI) pra voce a implementacao da interface.
Confuso ainda?

Simplificando hoje voce tem o seu sistema utilizando JDBC/Hibernate3.

public final class ServiceJdbcDao implements ServiceDao{ }
public final class ServiceHib3Dao implements ServiceDao{ }

Na classe que utiliza o Dao voce tera apenas a definicao da interface:

public final class Service{
   private ServiceDao serviceDao; // get & set - omitidos
   public Serializable serviceDone(Date time){
      // usa o dao e registra que hora o servico foi concluido
   }
}

A implementacao injetada na classe que utiliza o Dao pode ser alterada facilmente
no arquivo de configuracao do Spring…

Hoje voce usa JDBC amanha decide por motivos de escalabilidade mudar pra Hib3.
Vai saber…

O importante e estar pronto para as mudancas… (que muitas vezes nao ocorrem)
Boa sorte no projeto… :slight_smile:

[quote=Marcio Duran]
“Para quem não quer falar muito, o Spring utiliza a orientação a aspectos para fazer o controle de transações”
[/quote]

Voce diz uso do tx:advice ?
Poise, existem outras maneiras de se fazer isso, uma e utilizando proxy…

Fiquei confuso, tem como explicar melhor isso?
Valeu!

Bom você poderia expor tal argumentação, já que você citou advice , é a implementação do seu aspecto e também indica a forma que será executado em um determinado join point.
Os tipos de advice são:around(em volta do join point), before(antes)e after(depois).

[quote=keller][quote=Marcio Duran]
br.com.jm.springfsf.facade - inclui a classe que representa o Façade utilizada na aplicação.(lógica de negócios), fazemos apenas delegação de acesso a dados à layer tier data e controle transacional.
[/quote]

Fiquei confuso, tem como explicar melhor isso?
Valeu![/quote]

Verdade, vamos para um exemplo com (objetoKellerDao e objetoKellerFacadeImpl ) então :shock:

<?xml version="1.0" encoding="UTF-8"?> <beans...> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClasseName"> <value>com.mysql.jdbc.Driver</value> </property> <property name="url"> <value>jdbc:mysql://localhost/objetoKeller</value> </property> <property name="username"> <value>root</value> </property> <property name="password"> <value></value> </property> </bean> <bean id="jdbcTemplate" class="org.org.springframework.jdbc.core.JdbcTemplate"> <construtor-arg ref="dataSource"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="listar*"read-only="true"/> <tx:method name="consultar*"read-only="true"/> <tx:method name="*"propagation="REQUIRED"/> </tx:attributes> </tx:advice> <aop:config> <aop:pointcut id="facadeOperations" expression="execution(*br.com.jm.springjsf.facadeImpl.*(..))"/> </aop:advisor advice-ref="txAdvice" poincut-ref="facadeOperations"/> </aop:config> <bean id="objetoKellerFacade" class="br.com.jm.springjsf.facade.objetoKellerFacadeImpl"> <property name="objetoKellerDao" ref="objetoKellerDao"/> </bean> <bean id="objetoKellerDao" class="br.com.jm.springjsf.dao.objetoKellerDaoImpl"> <property name="objetoKellerDao" ref="objetoKellerDao"/> </bean> </beans>

Claro:

<!-- this example is in verbose form, see note later about concise for multiple proxies! -->
<!-- the target bean to wrap transactionally -->
<bean id="petStoreTarget">
  ...
</bean>

<bean id="petStore" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
  <property name="transactionManager" ref="txManager"/>
  <property name="target" ref="petStoreTarget"/>
  <property name="transactionAttributes">
    <props>
      <prop key="insert*">PROPAGATION_REQUIRED,-MyCheckedException</prop>
      <prop key="update*">PROPAGATION_REQUIRED</prop>
      <prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
    </props>
  </property>
</bean>

Fonte: http://static.springframework.org/spring/docs/1.2.x/reference/transaction.html
Vide: 8.5. Declarative transaction management

Eu nao disse que advice e a implementacao do meu aspecto, apenas questionei. :thumbup:
Pensei ser mais comodo cita-lo pois ele e utilizado como exemplo na documentacao do Spring…
Doc. Spring2: http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html

Mas o ponto e, existem outras formas(como ja mostrei).
Sem flamewar ultimamente estou vendo o GUJ como um campo de batalha.

Abraco.

Heheheh, bom senso de humor.

Mas a questao nao era essa, acho que ficou mal explicada a duvida, desculpa.
A minha duvida era, voce esta implementando as regras de negocio na Facade?

Acredito que essa nao e a motivacao desse pattern.
*Fonte: http://en.wikipedia.org/wiki/Facade_pattern
Como voce pode ver o Facade faz as chamadas as regras de negocio.

Estou dizendo isso porque foi o que voce deixou a entender(pelo menos na minha opniao).
*E ultimamente expor opniao no GUJ tambem esta complicado… :?

:arrow:- Click aqui !!:idea:

Não me preocupo apenas em fazer o código funcionar, mas busco resolver o problema da forma mais simples possível. (KISS :!: :))

Estava justamente querendo esclarecer os conceitos das interfaces, pois estava enxergando elas apenas como entulho :lol:.

Obrigado pelas respostas.