Унаследаться от static class?
Унаследаться от static class?
У меня снова нестандартный вопросик...
имеем вот такой список определений имен полей в таблице:
using System;using System.Text;
namespace LiOrder.DAL.Glass{public static partial class GLAS_DATEN{public static class FieldName{public const string IDs = "IDNR";public const string Type = "GL_TYP";public const string Bez = "GL_BEZ";public const string KzBez = "GL_KZ_BEZ";public const string BezJn = "GL_BEZ_JN";public const string Wagr = "GL_WAGR";public const string OptJn = "gl_opt_jn";public const string KenLip = "gl_ken_lip";public const string Dicke = "GL_DICKE";public const string MaxSeit1 = "GL_MAX_SEIT1";public const string MaxSeit2 = "GL_MAX_SEIT2";public const string Version = "gl_ver_pro";public const string MaxBreite = "gl_stat_max_breite";public const string MaxHoehe = "gl_stat_max_hoehe";public const string MwstCode = "GL_MWST_CODE";public const string MatKat = "GL_MAT_KAT";public const string MatBlock = "GL_MAT_BLOCK";public const string AbschichtJn = "GL_ABSCHICHT_JN";public const string LagerFuehrung = "gl_lager_fuehrung";public const string BeschStrukt = "GL_BESCH_STRUKT";public const string FloatDicke = "GL_FLOAT_DICKE";public const string KompAufbauJn = "GL_KOMP_AUFBAU_JN";public const string GrafikFile = "GL_GRAFIK_FILE";public const string FarbNo = "GL_FARB_NR";public const string LagermasseJn = "gl_lagermasse_jn";public const string ZeichngRef = "GL_ZEICHNG_REF";public const string BearbJn = "GL_BEARB_JN";public const string StdBreite = "GL_STD_BREITE";public const string StdHoehe = "GL_STD_HOEHE";public const string SdGroup = "GL_SD_GRUPPE";public const string AlphaID = "GL_ALPHA_ID";}}}
класс статический - экземпляры создаваться не будут.
Имена полей в таблице менятся, скорее всего, тоже не будут, а вот используемые константы-маркеры в теле будут уточнятся регулярно. Я просто не знаю что подразумевается под имеющимися именами и переименовываю в-то-что-мне-удобно по мере узнавания.
Помимо списка полей внутри
public static partial class GLAS_DATEN
определены классы таблицы, строки, выборки и некоторые другие.
Для полной приятности разработки все поделено на уровни - ДАЛ, БО, БЛ и т.д. и т.п.
Естественно, на каждом уровне нужен доступ к этому списку.
Частично это решается путем определения
using FieldName = LiOrder.DAL.Glass.GLAS_DATEN.FieldName;
Частично - потому как в этом случае список получается не расширяемым.
А мне как раз потребовалось его расширить. При этом копы-пасте делать совсем не хочется.
Есть какой вариант "унаследоваться" от статического класса и расширить списоk?
имена как имена, вроде говорящие сами за себя, зачем их переименовывать?
ну парочка немножко непонятна, но думаю если контекст ясен, то и они станут понятными.
Не затруднит объяснить что именно хранится в поле с именем
public const string KzBez = "GL_KZ_BEZ";
и как перейти от имеющегося к приемлемому английскому варианту. Бо, Я - не немец, Я - англик и вокруг немцев немае...
Суммарный контекст - 700+ таблиц без реляций... и эта еще не самая большая...
я бы сказал Kurzbezeichnung т.е. короткое наименование
вообще-то в проектах где учавствовал сокращение KZ используется для Kennzeichen тоесть какая-то абревиатура, код чего-то, сокращение. но тогда пишут что-то типа MATERIAL_KZ. но так же из опыта часто имееются два поля, длинное и короткое имя/наименование. поэтому сделал такой вывод.
Не устраивает необходимость править 4-ре уровня при изменении...
А зачем делать так как тебе не нравится? и не пробуй перименовывать намеспейс 
А с именами - енто их любимое занятие. У всех с английским проблем нет, но всё норовят на немецком сделать, задолбался переименовывать.
KZ_BEZ может быть Short name
но всё норовят на немецком сделать, задолбался переименовывать.
у нас сказали, кто таким заниматься будет - пожалуйста, но только в свое свободное (неоплачиваемое) время.
т.е. речь идет не о лучших названиях, которые лучше показывают применение/назначение, а чисто переименование с одного языка на другой(как с немецкого на англицкий так и с англицкого на немецкий).
У нас есть маленький ньюанс. Так как я писал style guide, то не забыл упомянуть что "язык софта" англицкий. А так как всё с этим положением согласились, то я "привожу софт в порядок", причем только те части которые меняю.
Хотя в самом начале хорошо пролетел. Просто автоматом добавил неймспейсы, после этого софт перестал загружаться.
когда подключили индийцев, тоже было распоряжение - усе на англицком писать и теперь кто писал дальше на немецком стал править на англицкий в свое свободное время
edit: но заметьте, здесь была конкретная обоснованная цель. а не просто так, потому что кому-то одному удобнее.
Так дело, то не в удобстве для "одного", а в неком стандарте.
А с индийцами я даже сам завязал. Раздавали они как то бесплатно либу для "частников" https://www.syncfusion.com/.
Какое то время помучился сам, помучил саппорт и теперь перешел опять на опен соурсе. Мышление у них какое то другое, слишком "плоское" и "инопланетное".
Ну так и что с того что там в базе наваяли?
Мне нужно чтобы в коде было понятно что делается. Значит в БО надо делать правильные имена.
Удобнее всего это делать списком в неинстанцируемом объекте. Примерно как написано.
А вопросик в том как его расширить на следующем уровне - там добавляются вычисляемые поля.
Удобнее всего это делать списком в неинстанцируемом объекте. Примерно как написано.
что то начинаю вспоминать тоже нужен был подобный список для ид. Так вначале игрался с константами и рефлектион, затем с енумами (в каждом енуме была метка окончания), а после начали пользовать один большой "разряженный" енум (когда группы начинаются например, каждую 1000).
Тебе то по идее нужен маппинг константы со строкой.
Делаем класс с дистионари(енум, строка) и наполняем как хочется.
Я еще ни разу не видел "нормальной немецкой схемы" бд. Мало того что поля исключительно на нем.
это критерий для "нормальности"?
так и валом различных извращений.
извращения, которые я видел и назвал бы их таковыми, были написаны в основном программистами-самоучками. а таких было в Германии в 80-х довольно таки много. и не смотря на это софт написанный ими до сих пор используется.
также есть другая категория извращений - это когда "тогдашние" БД не предоставляли все возможности которые сейчас есть
третья категория - это когда действительно руками за голову берешься и готов бы руки поотрывать. пока никто не "переплюнул" случай - m:n-relationship реализовна без промежуточной таблицы. каждая энтити ID другой сохраняла и просто в проге/клиенте фильтровалось что к чему.
это критерий для "нормальности"?
нет, но это визитная карточка с рекламой - мы оптимизировали нашу базу до 0НФ
это софт написанный ими до сих пор используется
Есть один такой. Самый писк там - синглетоны для каждой переменной!
Работает исключительно героическими усилиями авторов. Ходишь как по минному полю.
Тебе то по идее нужен маппинг константы со строкой.
-----
Мне почти без разницы что именно там будет - строка или целое.
Почти - при использовании целого все должно работать чуток быстрее, но в паре мест - там где строится фильтр и там где печатается строка данных нужны строкi.
Делаем класс с дистионари(енум, строка) и наполняем как хочется.
-----
А примерчик? Особливо интересует как он будет расширятся в другой либе.