Arquivo Discussoes de Programacao e Tecnologia Oi, sou eu de novo…
fiz o swing funfar com DAO, FactoryDAO, VO…
mas o seguinte:
Como vou fazer com a conexão?
1ª Forma: Pego a conexão pela classe que tem o método main() e fico passando por referência para os meus métodos de inserir, alterar, exluir… de cada BD;
2ª Forma: Declaro uma variável static do tipo Connection na Classe que tem o main() e pego em cada método de inserir, alterar, excluir… MainClass.VarStatic;
o que é melhor? ou pior? Alguém já fez isso?
Att, Rodrigo
Olá,
1 - Por que você está usando VO/TO/DTO?
Usando DAOs, instancie eles, talvez com uma Factory, em cada uso.
Rodrigo, da uma olhada nesse link, tem exemplo de factory em DAO pra resolver esse teu problema de uma forma legal
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Matheus já fiz como está no http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.
Tu já tinha me dito isto e também eu já conhecia este… mas como estou adaptando para swing… não sei como fazer com a conexão. Cheguei nestes dois exemplos que falei lá em cima…
Não tenho um web conteiner para ficar pegando conexões…
então eu faço uma vez a conexão e passo pros métodos…
ou crio uma varável estática e chama ela no método atravéz do classe principal…
estou com dúvidas sobre isto…
e tu notou esses exemplos no link? :roll:
CloudscapeDAOFactory// Cloudscape concrete DAO Factory implementation
import java.sql.*;
public class CloudscapeDAOFactory extends DAOFactory {
public static final String DRIVER=
"COM.cloudscape.core.RmiJdbcDriver";
public static final String DBURL=
"jdbc:cloudscape:rmi://localhost:1099/CoreJ2EEDB";
// method to create Cloudscape connections
public static Connection createConnection() {
// Use DRIVER and DBURL to create a connection
// Recommend connection pool implementation/usage
}
public CustomerDAO getCustomerDAO() {
// CloudscapeCustomerDAO implements CustomerDAO
return new CloudscapeCustomerDAO();
}
public AccountDAO getAccountDAO() {
// CloudscapeAccountDAO implements AccountDAO
return new CloudscapeAccountDAO();
}
public OrderDAO getOrderDAO() {
// CloudscapeOrderDAO implements OrderDAO
return new CloudscapeOrderDAO();
}
...
}
// CloudscapeCustomerDAO implementation of the
// CustomerDAO interface. This class can contain all
// Cloudscape specific code and SQL statements.
// The client is thus shielded from knowing
// these implementation details.
import java.sql.*;
public class CloudscapeCustomerDAO implements
CustomerDAO {
public CloudscapeCustomerDAO() {
// initialization
}
// The following methods can use
// CloudscapeDAOFactory.createConnection()
// to get a connection as required
public int insertCustomer(...) {
// Implement insert customer here.
// Return newly created customer number
// or a -1 on error
}
public boolean deleteCustomer(...) {
// Implement delete customer here
// Return true on success, false on failure
}
public Customer findCustomer(...) {
// Implement find a customer here using supplied
// argument values as search criteria
// Return a Transfer Object if found,
// return null on error or if not found
}
public boolean updateCustomer(...) {
// implement update record here using data
// from the customerData Transfer Object
// Return true on success, false on failure or
// error
}
public RowSet selectCustomersRS(...) {
// implement search customers here using the
// supplied criteria.
// Return a RowSet.
}
public Collection selectCustomersTO(...) {
// implement search customers here using the
// supplied criteria.
// Alternatively, implement to return a Collection
// of Transfer Objects.
}
...
}
note este comentário no CloudscapeCustomerDAO: :grin:
// The following methods can use
// CloudscapeDAOFactory.createConnection()
// to get a connection as required
Sim, exatamente como está desctito. A minha DAOFactory é abstrata.
public abstract class DAOFactory {
/** tipos de DAO suportados pela factory */
public static final int MYSQL = 1;
public static DAOFactory getDAOFactory(int factory) {
switch (factory) {
case MYSQL: return new MySQLDAOFactory();
default: return null;
}
}
/** implementacoes para as classes concretas * */
public abstract ConexaoDAO getConexaoDAO();
public abstract ClienteDAO getClienteDAO();
public abstract MunicipioDAO getMunicipioDAO();
}
Só mudei o nome das classes e dos métodos.
Mas note que ali (j2ee) existe um web conteiner que gerencia tuas conexões ao BD, certo? Mas numa máquina local não preciso ficar fazendo conexões a torto e a direito. Somente uma conexão quando o kara faz login e desconexão quando fecha o programa... :sad:
Rodrigo
vc deve estar se referindo a isso:
// method to create Cloudscape connections
public static Connection createConnection() {
// Use DRIVER and DBURL to create a connection
// Recommend connection pool implementation/usage
}
tu pode renomear ele pra getConnection(), e conectar ao banco como esta fazendo por ele, e retornar esta conexão dele, é a unica alteração… 
tu pode renomear ele pra getConnection(), e conectar ao banco como esta fazendo por ele, e retornar esta conexão dele, é a unica alteração… :)
Sim. Blz. Mas quando vou usar, por exemplo, a MySQLDAOFactory recebe uma variável estática Connection. Então a minha MySQLClienteDAO, que é a classe que eu faço os insert(), update(), pega MySQLDAOFactory.VariavelStatica e tenho a conexão.
Isto esta certo fazer assim?
Achei que ficou bom… e minhas classes de swing não saber nada de Connection… só precisam saber qual a factory…
Que se acha?
Rodrigo
P.S.: Obrigado até agora pela atenção… :lol:
bem… veja só, vamos analisar… hehehe, nesse pattern, se tu usar um pool, qual é o lance… é tu recuperar uma conexão antes de fazer uma consulta/insert oq for, e logo q fazer tu libera a conexão… certo? esse é um dos princípios de se usar pool… ok, agora, se tu usar uma conexão fixa com o banco, no getConnection vai te retornar a mesma referencia pra todos os DAOs, isso pq tu nao tem um pool pra gerenciar tuas conexões… bem, não sei se é a melhor maneira de se fazer qnd tu tem uma única conexão statica… mas ao meu ver esta legal…