Ainda ando às voltas a tentar encontrar a minha persistência perfeita. Ou pelo menos tento.
Já tentei muitas formas como: NHibernate ou ActionPack, mas, nenhuma delas funciona da melhor forma. Há sempre algo que não gostaria que fizesse dessa forma.
Com o Nhibernate temos que criar os ficherios XML com a informação sobre os campos e relação entre as entidades. Há algumas coisa a dizer? Para que quero eu fazer isso?
Os mais puristas dizem logo, como crias a relação entre o objecto e uma tabela (nome da tabela e colunas)? É verdade, mas, tem que haver uma forma melhor para fazer isto.
Com o ActionPack (antigo .NET on Rails), parecia que era o Santo Gral da persistência. Com base em parametrizações no Web.Config tinhamos acesso a objectos criados dinamicamente com a base de dados toda... UAUUUU.
Toda a princesa tem sempre joanetes e esta tem os seus. Só funciona com o template de projecto WebSite, pois, usa um mecanismo dinâmico (que não sei bem explicar) associado ao App_Code, isto é, usando o template WebApplication ou outro qualquer template (Windows Application, Console Application ou Class Library) não vai funcionar. Temos que criar novamente ficheiros XML com a definição da base de dados.. AAAAAAARRRRRRRGGGGGGGGGGG.
Qual a minha alergia aos ficheiros XML de parametrização? Tudo tem haver essencialmente com actualização / criação da informação. É inevitável o trabalho a criar tabela ou view na base de dados. Podemos considerar o trabalho de criar o objecto na aplicação inevitável, mas, ainda termos que criar um ficheiro XML? Já imaginaram o trabalho de manutenção sempre que temos que alterar/adicionar/apagar um(ns) campo(s)?
Isto sem falar em termos que dominar 3 formas de declarar o nosso objecto (na base de dados, no objecto e no ficheiro XML).
Por isso resolvi colocar a mão na massa e perguntar à comunidade o que acham sobre e resolvem este problema.
Qual a minha proposta?
Para resolver este problema e para abdicar definitavamente do ficheiro XML com a definição dos vários campos da base de dados resolvi adicionar ao objecto definido na aplicação as diversas propriedades como exemplo:
[Table("tbl_User")]
public class tbl_User
{
#region Private Fields
private int _userID;
private string _userName;
#endregion
#region Public Properties
[IsIdentity, PrimaryKey]
public int UserID
{
get { return _userID; }
set { _userID = value; }
}
public string UserName
{
get { return _userName; }
set { _userName = value; }
}
#endregion
}
Associado à classe temos a tabela ou view e a todas as propriedades podemos ter:
* IsIdentify - Caso o campo seja do tipo Identify ou AutoNumber
* PrimaryKey - Caso o campo esteja definido na base de dados como Chave Primária.
* ColumnName - Caso o nome da propriedade seja diferente do campo da base de dados, este campo deve ser atribuido. Se não for atribuido o sistema de persistência vai usar o nome da propriedade.
* IsNullable - se na base de dados o campo pode conter NULL como
valores. Atribuir o MinValue a um campo Data ou Int32 irá corresponder a NULL na base de dados.
* NotSerializable - A propriedade não será sarializada
* CrossReference - (ainda não implementado) Irá ser responsável por criar uma relação do tipo 1-1.
* MasterDetail - (ainda não implementado) Irá Conter uma lista de objectos de detalhe relacionados com a tabela principal.
Claro que poderei ter mecanismos para gerar estes objectos, mas, a manutenção deste objecto será efectuada a quando se efectua qualquer alteração na base de dados.
Desta forma ultrapassamos a necessidade de um ficheiro XML com estas definições.
No próximo post irei mostrar como interagimos com este objecto para efectuar acções sobre a base de dados. Alguém lembra-se de mais alguma propriedade que deva ser considerada?
Abraços
Paulo Aboim Pinto