A classe User é abstrata e existe apenas estes dois atributos. As classes que herdam servem apenas para diferenciá-los e não possuem atributos diferentes. Como criar essa tabela User no banco? Melhor… depois quando precisar buscar os dados no banco…como saber quem é admin ou um usuário normal?
Fiz algo parecido no meu projeto, não sei se está da forma correta, vê se te ajuda em algo:
veja as imagens utilizando Servlet :
O mesmo projeto so que utilizando Struts : Gitub .
Modelagem :
Tabelas do Banco:
na minha tabela USUARIO eu tenho um campo chamado TIPO , esté campo ira conter a informação se ele é um UsuarioVip ou UsarioNormal.
na minha pagina fiz assim :
<form action="InserirUsuarioForm.do" method="POST">
Tipo de Usuários<br />
<input type="radio" name="rdbTipo" id="tipoVip" value="UsuarioVip"/>
<label for="tipoVip">Usuário Vip</label> <br />
<input type="radio" name="rdbTipo" id="tipoNormal" value="UsuarioNormal"/>
<label for="tipoNormal">Usuário Normal</label> <br />
</form>
O metodo incluir do DAO :
@Override
public void incluir(Usuario entidade) throws SQLException {
stm = conexao.prepareStatement("INSERT INTO USUARIO VALUES (?,?,?,?,?,?)");
stm.setString(1, entidade.getLogin());
stm.setString(2, entidade.getSenha());
stm.setString(3, entidade.getNome());
stm.setString(4, entidade.getTelefone());
stm.setString(5, entidade.getEmail());
stm.setString(6, entidade.getClass().getSimpleName()); // aqui ele ira pega o nome da classe
stm.executeUpdate();
stm.close();
}
Controller:
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
RequestDispatcher view = null;
Usuario usuario = null;
String mensagem = null;
DAOFactory df = null;
InterfaceDAOUsuario daoUsuario = null;
try {
df = DAOFactory.getDaoFactory(DAOFactory.ORACLE);
daoUsuario = df.getDAOUsuario();
// aqui faz a verificação de qual tipo será armazenado
if(request.getParameter("rdbTipo").equals("UsuarioVip")) {
usuario = new UsuarioVip();
} else {
usuario = new UsuarioNormal();
}
usuario.setLogin(request.getParameter("txtLogin"));
usuario.setSenha(request.getParameter("txtSenha"));
usuario.setNome(request.getParameter("txtNome"));
usuario.setTelefone(request.getParameter("txtTelefone"));
usuario.setEmail(request.getParameter("txtEmail"));
daoUsuario.incluir(usuario);
request.setAttribute("user", usuario);
mensagem = "Inclusão de Usuario realizada com sucesso";
}Eu não vejo por que usar um “dao usuario”.
O DAO deveria retornar o objeto certo, e usar polimorfismo pra retornar uma interface ou subclasse adequada.
Pra criar o usuario certo basta usar um padrão de criação como Factory e fabricar a coisa certa.
Se vc precisa criar o objeto q partir do form, use a factory adequada.
À lógica do que é esse objeto esta na camada MODEL e existe um detalhe da infraestrutura que serializa isso no banco. O que pode dificultar é usar um objeto pra receber o form – ai nao sei como resolver pq sou um homem das cavernas que não usa as coisas mais recentes
Isso é solução acadêmica, na prática só vai te trazer complicação técnica. Eu colocaria um campo booleano admin na tabela User, se é este o caso de controlar quem é administrador de forma fixa. A solução mais abrangente costuma ser com tabelas de perfis x permissões, mas considerei seu cenário.
Dependendo da modelagem é melhor ter
metodoQqCoisa(Admin admin){…}
Do que la dentro vc fazer if admin == true, else, etc
Perceba que isso não é escrito em pedra.
E as vezes vc tem algo como CATEGORIAS bem diferentes de usuarios que um simples boolean não resolve.
Mas é um “as vezes”.
O daoUsuario é o que contem os métodos para o crud.
Isso era um trabalho da faculdade, onde o professor ensinou desta forma.
O único padrão que estou usando é o Dao do jee .
Entendi… mas… confesso que realmente não gostaria de meter um if para verificar se o cara é admin ou não…
Entendo que não quer if. Mas como você vai saber se um usuário é da classe Admin? Vai ter que haver uma consulta de qualquer forma, se vai numa tabela diferente ou num campo, não faz diferença pra funcionalidade.
Você está certo…não vou ter para onde correr…vou utilizar a idéia do Daniel_Dias… criei um atributo na classe abstrata User… e no momento da autenticação é criado um UserNormal… se depois de verificar no banco que é um UserAdmim, faço a mudança…
Exato, ai fica como uma escolha técnica que você vai levar na vida da sua aplicação. Importante para a empresa é que os dados compartilhados pelos tipos de usuário estarão sem complicação numa mesma tabela no banco de dados. De uma forma ou de outra a informação terá que ser consultada no banco relacional obedecendo condições (ou ifs como quer chamar), independente se a aplicação “A” usa modelagem orientada a objetos e fica se preocupando com mapeamentos/truques de mágicas, ou se a aplicação “B” simplesmente faz direto um SQL para retornar o resultado da funcionalidade.
Banco relacionais não lidam com objetos (e herança), lidam com relações. Se quer saber como mapear sua estrutura de objeto para o modelo relacional, a resposta vai depender do que vc usa na camada ORM.