Здравствуйте, FDSC, Вы писали:
FDS>В .NET всегда было двоякое наименование методов: допускалось и с большой буквы наименовать, и с маленькой, насколько я помню. Классы — да, с большой.
FDS>getEquipmentChilds.init();
FDS>getEquipmentChilds.ended.waitOne(); // можно просто getEquipmentChilds.wait() или getEquipmentChilds.waitOfEnd(), если периписать свойство на метод
FDS>def childrens = getEquipmentChilds.ewObject.words; // а уж это немерлист спокойно поймёт, т.к. семантика getEquipmentChilds().words, просто скобки убрали
FDS>
Ну, хотите get, так get
C>>Кстати, публичные изменяемые поля считаются моветоном.
FDS>Согласен, можно добавить лишнее свойство для ErrCode и ErrMsg, но это не суть важно. В данном случае это совершенно ничему не мешает, а писать лишний код только для того, чтобы он соответствовал всем канонам программирования — увольте: я пишу так, как мне удобно, там, где это может повредить, все публичные поля помечены как readonly (да и возится с защитой списка через предоставление интерфейса — я считаю, что это "моветон" практически всегда, это я вместо дела только и буду сам от себя защищать очевидные вещи и мешать, тем самым, себе программировать, т.к. инумератор обладает ограниченными возможностями и всё равно придётся в итоге открывать этот список).
Это плохой взгляд на вещи. Но я не собираюсь с Вами в этом плане спорить. Укажу только на три объективные вещи:
1. Объявление и использование автоматических свойств почти так же лаконично, как и полей.
2. Можно не IEnumerator, а ICollection, IList или IDictionary возвращать.
3. Child -> Children.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Ziaw, Вы писали:
Z>>В чем проблема? процесс назовем EquipmentChildrenReader, дадим ему 2 публичных метода, Read и ReadAsync.
FDS>Не против. Только get короче писать, чем Reader, кроме этого, если нужно что-то получить, потом вводишь .get, а VS сама тебе предлагает разные варианты, с Reader так не получится — неудобно.
Z>>Не очень понятно что этот класс абстрагирует, если процесс асинхронного чтения — зачем ему ORM функции? Мой совет — взять блтулкит и не изобретать ORM.
FDS>1. Производительность. Я в своё время пользовался hibernate, в связи с тем, что работало это полчаса вместо 1-ой минуты своего sql: больше никогда не использую такие вещи.
hibernate тот еще тормоз, особенно если юзать его в лоб.
Производительность тулкита без линка чуть ниже нейтив ридера. http://rsdn.ru/projects/rfd/linq/LinqWithBLToolkit.xml#E6VAG
FDS>2. Мне легче написать класс, чем настроить какой-либо инструмент автоматического извлечения
Так не один же класс будет.
FDS>3. Я не знаю, что он будет делать, если часть данных поменяется (может, он всю базу заново выкачает?)
Он качает только то, что попросят.
FDS>4. Всё равно останутся классы изменения таблиц
Не понял что за классы.
FDS>5. Что будет, если у пользователя нет прав на получение таблицы?
То же что и в нейтив ридере.
FDS>6. Я не люблю, когда всё не очень удобно и при этом не под контролем, а ORM — это не удобно (по крайней мере, прежде чем станет удобно, пройдёт много времени) и существенно уменьшает уровень контроль над чтениями БД.
Тулкит дает полный контроль.
Z>> Кто гарантирует, что запрос выбирает то, что захардкоженно в классе? FDS>Не понял вопроса.
В класс передается произвольная query, а в нем захардкожены имена полей которые обязаны быть, иначе чтение упадет.
Z>>Я не юзал MySql, но в других базах шарить один конекшн на несколько тредов противопоказано, в вашей архитектуре очень неопределенно время жизни конекшена и транзакции.
FDS>А кто шарит коннекшн на несколько тредов? FDS>Время транзакции определено и коннекшена определено (если не считать ConnectionPooling, т.е. того, что брошенный мною коннект может быть не закрыт, а отдан для дальнейшего использования) FDS>Даже не понял, с чего вы взяли, что это не так
С того, что запрос лежит в синглтоне.
Z>>Не увидел никакого смысла в статиках, кроме головной боли. FDS>Не понял.
Какое место? Статик зачем?
Здравствуйте, Ziaw, Вы писали:
Z>>>Не очень понятно что этот класс абстрагирует, если процесс асинхронного чтения — зачем ему ORM функции? Мой совет — взять блтулкит и не изобретать ORM.
Z>Производительность тулкита без линка чуть ниже нейтив ридера. http://rsdn.ru/projects/rfd/linq/LinqWithBLToolkit.xml#E6VAG
Не думаю. Неоптимизированный запрос был быстрее hibernate всего в два с небольшим раза. Оптимизированный — в 30. Вряд ли БЛТулкит оптимизирует запросы (конечно, это имеет значение, если данных много и запросы сложные).
Z>Так не один же класс будет.
Это да. Но ведь и с инструментом нужно разобраться. Кроме этого, насколько я понимаю, мне всё равно нужно описывать объект — а это самое тяжёлое в написании таких классов.
FDS>>4. Всё равно останутся классы изменения таблиц Z>Не понял что за классы.
Классы, которые должны изменять данные внутри БД. Система реализована так, что пользователь не имеет права сам вызывать insert/update/delete, всё это делается через хранимые процедуры.
FDS>>5. Что будет, если у пользователя нет прав на получение таблицы?
Z>То же что и в нейтив ридере.
Ты уверен? Где он установит статус, где мне посмотреть сообщение об ошибке?
Z>Тулкит дает полный контроль.
Он сам генерирует SQL, ведь так? Значит — не полный.
Z>В класс передается произвольная query, а в нем захардкожены имена полей которые обязаны быть, иначе чтение упадет.
Нет, sql запрос прямо в классе захардкожен.
Вот эта строка
reader = query.executeReader("select ID, parentCatID, childCatID from equipmentChildsView");
query — это строка коннекта к БД (имя, пароль, имя базы данных, кодировка)
Z>>>Я не юзал MySql, но в других базах шарить один конекшн на несколько тредов противопоказано, в вашей архитектуре очень неопределенно время жизни конекшена и транзакции.
Z>С того, что запрос лежит в синглтоне.
Не понял.
Z>>>Не увидел никакого смысла в статиках, кроме головной боли. FDS>>Не понял. Z>Какое место? Статик зачем?
Там много статиков и все они нужны. Не понял, что вам в них не нравится.
Re[8]: Оффтопик: get в имени класса с точки зрения немерлист
А, ну значит я обшибся. Сликом долго на java программировал, раньше я все методы с большой писал, а начальник мне говорил, что надо с маленькой
C>Ну, хотите get, так get
C>Это плохой взгляд на вещи. Но я не собираюсь с Вами в этом плане спорить. Укажу только на три объективные вещи:
Какие же они объективные?
C>1. Объявление и использование автоматических свойств почти так же лаконично, как и полей.
Кроме этого, не так же лаконично
Вместо
public int errCode = 0;
я должен написать
public int errCode {get; protected set;}
getEquimpentChilds()
{
errCode = 0;
}
Я ведь должен как-то инициализировать переменную?
C>2. Можно не IEnumerator, а ICollection, IList или IDictionary возвращать.
Сравни, сколько методов доступно для объекта типа List<>, а сколько для IList. Возвращая IList я ограничиваю функциональность больше, чем мне нужно, а я не люблю этого делать.
C>3. Child -> Children.
Здравствуйте, FDSC, Вы писали:
FDS>Не думаю. Неоптимизированный запрос был быстрее hibernate всего в два с небольшим раза. Оптимизированный — в 30. Вряд ли БЛТулкит оптимизирует запросы (конечно, это имеет значение, если данных много и запросы сложные).
Что тут думать? Я линк дал, там тесты есть. Запросы которые не смог оптимизировать оптимизатор придется оптимизировать руками, чудес не бывает.
FDS>Это да. Но ведь и с инструментом нужно разобраться. Кроме этого, насколько я понимаю, мне всё равно нужно описывать объект — а это самое тяжёлое в написании таких классов.
Спасибо, посмеялся. Тулкиту можно вообще не описывать объект, он будет считать, что имя таблицы совпадает с именем класса, а имена колонок с именами полей/свойств.
Вот очень простая таблица я больше ничего тулкиту про нее не говорил, он и так умеет читать, вставлять и удалять ее поля.
FDS>Классы, которые должны изменять данные внутри БД. Система реализована так, что пользователь не имеет права сам вызывать insert/update/delete, всё это делается через хранимые процедуры.
Зачем тут классы если есть процедуры? Тулкит умеет с ними работать, опять же сообщать ему о них надо минимум.
Z>>Тулкит дает полный контроль.
FDS>Он сам генерирует SQL, ведь так? Значит — не полный.
Может "сам" по написаному тобой linq, можешь ты лично. Это очень удобно.
FDS>query — это строка коннекта к БД (имя, пароль, имя базы данных, кодировка)
Очень удачно имя переменной выбрано.
Вобщем линия дискуссии понятна, сам знаю как тяжело понимать, что написал велосипед с треугольными колесами. Предлагаю закончить. Меня убеждать, что все в дизайне прекрасно не надо, мне как-то все равно.
Здравствуйте, FDSC, Вы писали:
FDS>Не против. Только get короче писать, чем Reader, кроме этого, если нужно что-то получить, потом вводишь .get, а VS сама тебе предлагает разные варианты, с Reader так не получится — неудобно.
Вот никогда так не думой о коде. Под пишется один раз, а читается много-много раз. По этому в первую очередь нужно думать о том как код будет читаться, а не писаться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Оффтопик: get в имени класса с точки зрения немерлист
Здравствуйте, FDSC, Вы писали:
FDS>Я ведь должен как-то инициализировать переменную?
Нулями — не должны. (то есть можете конечно, но не должны).
Не-нулями вы вряд ли часто будете инициализировать. Но всё равно, принято считать, что достоинства перевешивают недостатки.
Аргументы за использование свойств описал Джон Скит.
FDS>Сравни, сколько методов доступно для объекта типа List<>, а сколько для IList. Возвращая IList я ограничиваю функциональность больше, чем мне нужно, а я не люблю этого делать.
Значительная часть функциональности List<>, отсутствующая в IList, реализована в LINQ. Если даже вы не используете LINQ, в Nemerle продублирована (точнее, реализована раньше, чем LINQ) значительная часть этой функциональности (я говорю о Nemerle, потому что изначальный вопрос был об использовании Nemerle для улучшения вашего кода).
C>>3. Child -> Children. FDS>Лишние три символа
Тут извините, я хотел написать Childs -> Children. Лишних два символа. Только вот они не лишние.
FDS> Какие же они объективные?
Объективные-преобъективные
Re[9]: Оффтопик: get в имени класса с точки зрения немерлист
Вообще-то я не люблю обсуждать собеседника, но вы являетесь слишком классным примером человека, который, сравнивая две альтернативы, руководствуется их недостатками. Так делают часто и многие, а среди программистов, наверное, такое поведение особо заметно.
Рациональный выбор предполагает сравнение как издержек, так и выгод от использования каждого из вариантов, и на основе их соотношения приводит к выбору оптимального варианта. Если учитывать только издержки или только выгоды, то сравнение не всегда приводит к наилучшим результатам.
Примеры:
1. Автосвойства чуть менее лаконичны, чем поля. Инициализировать их ненулевыми значениями не так удобно. Поля, разумеется, такими недостатками не обладают. Но и достоинств у них, собственно, больше нет (кроме, разве что, возможности передачи поля класса как ref или out-параметра). А какие достоинства у свойств?
Возможности разграничения прав доступа (public get, private/protected set)
Бинарная совместимость при изменении размещения (переход в базовый класс, допустим) или изменении типа поля
Поддержка инструментов, использующих рефлексию
Бинарная и на уровне кода совместимость при замене поля на формулу
Возможность виртуальных или абстрактных свойств, которые изменяются в наследуемых классах.
2. IList обладает меньшей функциональностью, чем List. Это действительно так. Но ведь в .NET есть IList, и кто-то даже его использует, несмотря на узкую функциональность. Потому что IList обладает одним важным достоинством — можно поменять реализацию конкретного списка, не трогая код, который использует ту самую расширенную функциональность List.
Недавно я как раз использовал эту возможность. У меня в классе, который моделировал большое двумерное поле, использовался как контейнер IList<IList<T>>. Поскольку большинство ячеек этого поля пусты, я оптимизировал код, используя разреженные массивы (sparse arrays, структуры, которые ведут себя как массивы, только не нуждаются в памяти для пустых элементов). В результате, банальной заменой предыдущей dll-ки на новую, была произведена оптимизация программы в целом. Если бы я использовал List<List<T>>, то пришлось бы переписывать, а потом перекомпилировать все клиенты этой dll-ки.
Хотя использование свойств и интерфейсов имеет свои недостатки, эти недостатки с лихвой компенсируются достоинствами, поэтому использование таких конструкций более чем оправдано. Если же сравнивать только недостатки, то кажется, что свойства — это только лишние символы в программе, а интерфейсы только и делают, что ограничивают функциональность.
Здравствуйте, catbert, Вы писали:
C>1. Автосвойства чуть менее лаконичны, чем поля. Инициализировать их ненулевыми значениями не так удобно. Поля, разумеется, такими недостатками не обладают. Но и достоинств у них, собственно, больше нет (кроме, разве что, возможности передачи поля класса как ref или out-параметра).
И так, три достоинства:
1. Лаконичность
2. Удобство явной инициализации
3. Возможность передачи в поля как ref- или out-параметра (в данном случае — не нужно)
4. Ещё раз лаконичность, т.к. меня напрягает вспоминать краткое определение свойства без поля и вообще думать о нём
C> А какие достоинства у свойств? C>
C> Возможности разграничения прав доступа (public get, private/protected set
ok. Слабое достоинство, допустим, нейтрализует пункт 4 достоинства полей.
C> Бинарная совместимость при изменении размещения (переход в базовый класс, допустим) или изменении типа поля
Это вообще о чём? Что за бинарная совместимость и как я перемещу свойство в предок, если поле всё равно в потомке.
Итого: в данном случае достоинство не нужно и не будет использовано.
C> Поддержка инструментов, использующих рефлексию
В смысле? Я и публичное поле могу получить через рефлексию.
C> Бинарная и на уровне кода совместимость при замене поля на формулу
Мня, что за бинарная совместимость?
Поле я и так могу заменить потом на свойство (если оно, конечно, не было ref или out). Опять же, для данной переменной это никогда не пригодится (а если пригодится, то смогу заменить, т.к. для неё не нужны ref и out)
C> Возможность виртуальных или абстрактных свойств, которые изменяются в наследуемых классах.
Опть же, в данном случае совершенно не нужно C>
Итого, имеем 2 непогашенных преимущества декларации простого поля относительно автосвойства.
C>2. IList обладает меньшей функциональностью, чем List. Это действительно так. Но ведь в .NET есть IList, и кто-то даже его использует, несмотря на узкую функциональность. Потому что IList обладает одним важным достоинством — можно поменять реализацию конкретного списка, не трогая код, который использует ту самую расширенную функциональность List.
Опять же, в данном случае одно достоинство не нужно, зато недостаток может быть сразу прочувствован.
C>Недавно я как раз использовал эту возможность. У меня в классе, который моделировал большое двумерное поле, использовался как контейнер IList<IList<T>>. Поскольку большинство ячеек этого поля пусты, я оптимизировал код, используя разреженные массивы (sparse arrays, структуры, которые ведут себя как массивы, только не нуждаются в памяти для пустых элементов). В результате, банальной заменой предыдущей dll-ки на новую, была произведена оптимизация программы в целом. Если бы я использовал List<List<T>>, то пришлось бы переписывать, а потом перекомпилировать все клиенты этой dll-ки.
Я бы никогда не стал использовать сырой IList<IList<T>>, вместо этого я бы сделал удобный класс-интерфейс и сборки всё равно не нужно было бы перекомпилировать.
Вообще, в моей практике практически никогда не нужно было менять реализацию так, чтобы IList от этого спасал. Твой пример лишь пример неправильного подхода к проектированию
C>Хотя использование свойств и интерфейсов имеет свои недостатки, эти недостатки с лихвой компенсируются достоинствами, поэтому использование таких конструкций более чем оправдано.
Абстрактно — да, в реальности, как оказывается, далеко не всегда.
Примерно как "использование личного автомобиля имеет свои недостатки, эти недостатки с лихвой компенсируются достоинствами, поэтому использование таких автомобилей более чем оправдано" даже при езде в туалет на машине.
C> Если же сравнивать только недостатки, то кажется, что свойства — это только лишние символы в программе
Почему это?
Поля обладают по сравнению со свойствами кучей недостатков (см. перечисленные выше достоинства).
C> а интерфейсы только и делают, что ограничивают функциональность.
Нет, они ещё часто усложняют программирование за счёт повышения некоей мнимой гибкости
(не спорю, иногда они как раз нужны)
