Унаследаться от 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.
Делаем класс с дистионари(енум, строка) и наполняем как хочется.
-----
А примерчик? Особливо интересует как он будет расширятся в другой либе.
нет, но это визитная карточка с рекламой - мы оптимизировали нашу базу до 0НФ
связи не вижу между языком на котором названы переменные и вышесказанным
могу превести кучу проектов - где это не так.
Ходишь как по минному полю.
если так плохо - то ходить там не надо
Ну это еще пустяки - добавь к этому размер в 700 таблиц... с такими связями и... полное отсутствие реляций - вот тогда будет то что Я имею на сегодня.
спасибо - мне 2-х хватило.
это же способствует тому что не только прога/бд-организация - хлам, но и данные - такого же качества. не факт, но часто.
а что за БД?
а что за БД?
-----
Моя текущая производственная база. По секрету швейцарско-немецкого происхождения.
но и данные - такого же качества.
-----
Данные - это вообще что-то.
Вчера надо было импортировать машинный документ с другого (нашего же) заводика.
Конверсия из одного формата в другой уже давно написана и работает без проблем.
Но помимо конверсии еще нужна и трансляция данных.
Самое простое - поменять заказчика. Бо, для нас заказчиком будет другой завод.
И вот Я вижу название заказчика на экране... и нифига не могу найти где его хранят
в базе... а ошибка в одной букве даст ошибку в процессе импортa. Вот такая база...
Ну попробуй исключить язык из названий переменных.
Т,е. именовать их так - подчеркивание + девятизначное случайное число
и поработать с такой системой.
ну это только для вас и кто-там еще не знает немецкого, а мне говорю, понятно все более менее, причем вашего контекста я вообще не знаю, со знанием контекста и немного данных из БД, то наверно вообще все понятно будет.
если я буду говорить, что какой-то язык г...о, потому как я его не знаю - извините - но не аргумент это.
Прикреплённые файлы
и кто-там еще не знает немецкого
-----
Немецкоговорящих в мире менее 100 млн. Общая популяция - 7+ млд.
Так что правильнее говорить об тех кто по случаю знает немецкий.
И не ссылайся на отношение к языку. Языки, по крайней мере на территории
ЕС, являются официальным инструментом сегрегации - днями итальянцу
влепили штраф за неиспользование местного языка в бизнесe...
Немецкоговорящих в мире менее 100 млн. Общая популяция - 7+ млд.
Так что правильнее говорить об тех кто по случаю знает немецкий.
вот товарищу выше не нравятся иероглифы, а очень даже распространнены. так что тоже не аргумент.
И не ссылайся на отношение к языку. Языки, по крайней мере на территории
ЕС, являются официальным инструментом сегрегации - днями итальянцу
влепили штраф за неиспользование местного языка в бизнесe...
не знаю как у вас, в Германии есть закон о том, что в бизнесе, третье лицо должно в приемлемое время войти в курс бизнеса при проверках. т.е. нет никакого ущемления прав.
Вот нам прислали доку - часть иероглифами, часть на английском. Тем кто писал конечно удобно, не нужно две версии делать, но читать это совершенно ужасно.
ну это же не удобство или не неудобство. или знаем иероглифы(кстати, мур говорит, что очень распространенный язык, не должен вызывать неудобств
) или нет. если знаем - беремся за работу, если нет или нанимаем того кто знает или даем в перевод. что в обоих случаях увеличивает цену на выполнение заказа. на что обычно заказчик реагирует досыланием документации на языке, который ведет к удешевлению заказа.
третье лицо должно в приемлемое время войти в курс бизнеса при проверках.
-----
И проверяется, разумеется, не ведение бизнеса, а именно уровень владения языком и объем применения языка в ведении бизнеса.
так что тоже не аргумент.
-----
Ты уж реши - либо ты используешь это как аргумент, или не используешь.
В общем случае - количество программирующих с основным немецким языком гораздо менее всех остальных.
Ты уж реши - либо ты используешь это как аргумент, или не используешь.
В общем случае - количество программирующих с основным немецким языком гораздо менее всех остальных.
у меня противоречий нет, это вы ввели, что немецкий язык не такой распространенный. в то время как 
AlexNek вот на иероглифы жалуется.
я всего лишь сказал, что все, кто понимает язык на котором что-либо написано, для них не проблема понять. в вашем случае немецкий.
переименовывать (в ручную) из-за не знания языка - работа, которая может внести ошибки, которых не было. а так как работа муторная, "может" можно опустить.
третье лицо должно в приемлемое время войти в курс бизнеса при проверках.
И проверяется, разумеется, не ведение бизнеса, а именно уровень владения языком и объем применения языка в ведении бизнеса.
это ваше субъективное мнение основанное на не верном выводе. чиновники не поняв переписку, не знаю уж сколько процентов, но видимо значительную часть, просто не смогли в приемлемое время войти в курс дела, т.е. не смогли проверить бизнес как таковой.
а для вас это видится как ущемление прав на основе языковой принадлежности.
если вам вот оплачивают переписывание софта на другой язык, то им никто это не оплачивает. и видимо как и в Германии у вас есть на то законодательная база, что бы заствить "клиента" применять язык, понятный чиновникам. и не удивлюсь, что такие предписания есть во всех странах. отличие будет только, что в одной стране вы будете знать предписанный язык, а в другой - нет. вторая категория стран будет,
по вашему мнению, "ущемлять" ваши права.
все, кто понимает язык на котором что-либо написано, для них не проблема понять
-----
А что делать тем, кто знает свою работу, но не знает языка?
Отказываться от работы или все же подгонять под себя.
работа, которая может внести ошибки, которых не было. а так как работа муторная, "может" можно опустить.
-----
Т.е. ты хочешь сказать, что для тебя без разницы на каком языке все сделано.
Ну удачи тебе с арабскими письменами.
Что касается муторности... для замены идентификатора мне нужно всего лишь прописать алиас - генератор сделает остальное.
Ну это для меня.
Для всех остальных - будет гораздо меньше ошибок при работе с привычной терминологией, чем при работе с "отсутствующей" терминологией.
чиновники не поняв переписку
-----
Причем тут переписка? Я вроде точно написал - проверяется не документация по ведению бизнеса, которая ведется на местном языке, а проверяется именно уровень знания и объем применения языка в ведении бизнеса. Чтобы было понятно - существуют две отдельные государственные организации - одна проверяет ведение бизнеса - и у нее претензий к ведению итальянцем бизнеса не было никаких - и вторая - проверяет уровень знания и применения языка - у нее претензии к тому, что итальянец не применяет в ведении бизнеса местный язык. Это - ЕС и сегодня,
у вас есть на то законодательная база, что бы заствить "клиента" применять язык, понятный чиновникам
-----
Законодательная база, разумеется, есть.
Мне, например, в соответствии с этой законодательной базой, для работы прогером по найму, требуется знать и применять местный язык в соответствии с определением вышей категорией владения.
В каком месте пересекаются программирование и диалект небольшого (<800 тыс носителей), живущего на ограниченной (12 часов пешком поперек) и активно вымирающего (минус 50% за 26 лет) племени - это тебе пища для размышлений. И меня будут проверять и на наличие документа об уровне владения (тут итальянцу проще - ему доки не нужны), и на уровень владения, и на объем применения... при выполнении рабочих обязанностей.
А когда найдешь объяснения - подумай над тем, почему на той территории данные требования применяются только к части родившегося таm населения. Причем, чтобы было понятно, Мне нужно соответствовать этим требованиям и проходить проверки, а моему однокласснику - не нужно. А школу мы оба закончили одну и ту же.
Когда будешь готов обосновывать - поговорим.
Если ссылка на закон нужна - я тебе ее дам. Но не жалуйся на незнание языка - закон доступен только на местячковом диалекте.
Плюсиком будет расширяемость списка.
Остальное все будет минусом.
Из наиболее простых:
- для получения доступа к данным надо будет выполнять два поиска.
- для крупных систем (ну как у меня - 700 таблиц по 30-40 полей) енум будет большим.
- в енуме все поля будут одним большим списком, выделить контекстно не получится.
- отслеживать изменения в большом енуме будет более чем муторно.
- при работе со строкой данных мне не нужна итерация по полям. Когда потребуется - нужно будет организовывать массив, но не ранее. Хотя можно обойтись и целочисленным итератором.
Вроде так.
П.С. Понял, что написал непонятно.
> а именно уровень владения языком и объем применения языка в ведении бизнеса
Под этим надо понимать следующее - будет проверятся говорят ли между собой два итальянца в курилке на территории предприятия в рабочее время на местном (не итальянском) языке.
Если их работа, а организация и ведение бизнеса попадает под это требование на 100%, требует высшего уровня знаний языка, то использование в диалогах на местном языке итальянских междометий (напомню - разговаривают двое итальянцев) может быть классифицировано как недостаточное применение местного языка.
Именно за недостаточное использование - говорили между собой по-итальянски - языка в ведении бизнеса и выписан штраф...
ЕС, сегодня...
Плюсиком будет расширяемость списка.
А других требований и не было 
Это же "концепт" - делай как тебе нравится.
для получения доступа к данным надо будет выполнять два поиска.
пользователь этого не видит. Можно закинуть и в одно но мне так не нравится.
Поиск то не линейный.
для крупных систем (ну как у меня - 700 таблиц по 30-40 полей) енум будет большим.
А что мешает сделать енум на таблицу и пользоваться инт ключём?
при работе со строкой данных мне не нужна итерация по полям.
не пользуйся