Я использую custom attributes свойств классов, для автоматического формирования sql, который формирует базу данных, хранящую объекты этих классов.
Один из классов имеет private 2-мерный массив, который необходимо разложить по полям (не сохранять массив в одном поле). Для него я создал набор фиктивных свойств, которые не делают ничего, а лишь помечены атрибутом для формирования соответсвующего поля таблицы БД. Чтобы не захламлять интерфейс класса, я пометил эти свойства как private, но из-за этого я не могу считать свои атрибуты, а когда пометил один из свойств как public — в результирующем sql соответсвующее поле появилось.
Поэтому у меня вопрос: как использовать мою стратегию для автоматического написания sql-скрипта, но при этом не засорять интерфейс класса ничего не делающими свойствами?
А>Я использую custom attributes свойств классов, для автоматического формирования sql, который формирует базу данных, хранящую объекты этих классов. А>Один из классов имеет private 2-мерный массив, который необходимо разложить по полям (не сохранять массив в одном поле). Для него я создал набор фиктивных свойств, которые не делают ничего, а лишь помечены атрибутом для формирования соответсвующего поля таблицы БД. Чтобы не захламлять интерфейс класса, я пометил эти свойства как private, но из-за этого я не могу считать свои атрибуты, а когда пометил один из свойств как public — в результирующем sql соответсвующее поле появилось. А>Поэтому у меня вопрос: как использовать мою стратегию для автоматического написания sql-скрипта, но при этом не засорять интерфейс класса ничего не делающими свойствами?
Приватные поля можно перечислить через reflection. Код в студию, как ты читаешь свои "custom attributes"?
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Я использую custom attributes свойств классов, для автоматического формирования sql, который формирует базу данных, хранящую объекты этих классов. А>>Один из классов имеет private 2-мерный массив, который необходимо разложить по полям (не сохранять массив в одном поле). Для него я создал набор фиктивных свойств, которые не делают ничего, а лишь помечены атрибутом для формирования соответсвующего поля таблицы БД. Чтобы не захламлять интерфейс класса, я пометил эти свойства как private, но из-за этого я не могу считать свои атрибуты, а когда пометил один из свойств как public — в результирующем sql соответсвующее поле появилось. А>>Поэтому у меня вопрос: как использовать мою стратегию для автоматического написания sql-скрипта, но при этом не засорять интерфейс класса ничего не делающими свойствами?
S>Приватные поля можно перечислить через reflection. Код в студию, как ты читаешь свои "custom attributes"?
класс атрибута:
[AttributeUsage(AttributeTargets.Property,
AllowMultiple = false,
Inherited = true)]
public class DbFieldAttribute : Attribute
{
protected DbType m_fieldType;
protected int m_fieldLength;
public DbFieldAttribute(DbType fieldType)
{
m_fieldType = fieldType;
}
public DbType FieldType
{
get
{
return m_fieldType;
}
}
public int FieldLength
{
get
{
return m_fieldLength;
}
set
{
m_fieldLength = value;
}
}
}
помеченный класс:
...
[DbFieldAttribute(DbType.Int16)]
public int ItemCountAllF { get { return 0;}} // определяется
[DbFieldAttribute(DbType.Int16)]
private int ItemCountAllE { get { return 0;}} // !!! не определяется
...
...
PropertyInfo [] properties = type.GetProperties();
if (properties.Length == 0)
{
return null;
}
Table retTable = new Table(type,
tableAttribute.TableName,
tableAttribute.CreateGenerator,
m_connection);
foreach (PropertyInfo property in properties)
{
// creating message fieldsobject [] fieldAttribs = property.GetCustomAttributes(typeof(DbFieldAttribute), true);
if (fieldAttribs.Length != 0)
{
// there must be only one DbFieldAttribute assigned to a property
DbFieldAttribute fieldAttribute = (DbFieldAttribute)fieldAttribs[0];
Field newField = new Field(property.Name,
fieldAttribute.FieldType,
fieldAttribute.FieldLength);
retTable.AddField(newField);
continue;
}
...
Здравствуйте, Аноним, Вы писали:
А>Поэтому у меня вопрос: как использовать мою стратегию для автоматического написания sql-скрипта, но при этом не засорять интерфейс класса ничего не делающими свойствами?
Можно использовать реализацию, используюмую в колекциях: чтоб не засорять класс-колекцию членами MoveNext, Reset, Current, в класс добавляют лишь один метод GetEnumerator, который возвращает интерфейс со всеми необходимыми методами.
Вы уверены что не изобретаете велосипед? Думаю в инете можно найти кучу разных мапперов, которые делают то же самое, но при этом обладают гораздо большим количеством ф-льностей и некоторые из них лучшей производительностью (активное использование reflection сказывается на производительности очень сильно). Может стоит попробовать NHibernate, на данный момент, насколько я понимаю это один из самых популярных мапперов.
Это ни в коем случае не критика выбранного Вами способа работы с БД, а попытка подтолкнуть к размышлениям, которые (может быть) окажутся полезными.
Re[2]: custom attributes & members accessibility
От:
Аноним
Дата:
16.01.07 13:30
Оценка:
Здравствуйте, kostya.misura, Вы писали:
KM>Здравствуйте, Аноним.
KM>Извините, я может немного не в тему отвечу, но...
KM>Вы уверены что не изобретаете велосипед? Думаю в инете можно найти кучу разных мапперов, которые делают то же самое, но при этом обладают гораздо большим количеством ф-льностей и некоторые из них лучшей производительностью (активное использование reflection сказывается на производительности очень сильно). Может стоит попробовать NHibernate, на данный момент, насколько я понимаю это один из самых популярных мапперов.
KM>Это ни в коем случае не критика выбранного Вами способа работы с БД, а попытка подтолкнуть к размышлениям, которые (может быть) окажутся полезными.
спасибо за тыкание (действительно спасибо — обязательно посмотрю, вполне возможно, что изобретаю велосипед)
что касается производительности — да, я знаю, что reflection довольно ресурсоемкий, но я произвожу данную процедуру единократно для класса/таблицы, а затем при дальнейшем обращении использую уже сформированные структуры