Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ну, типа, вау. Но ты действительно не замечаешь разницы между внутренними механизмами сервера и тонами логики которые ты должен залить в сервер и там поддерживать?
View — это не внутренний механизм сервера. Это чистой воды логика, которую я должен залить в сервер и там поддерживать.
Stored Procedure — то же самое.
Я вообще не очень понимаю, чего вы стесняетесь. Имея, допустим, сервер на ASP.NET, вы что, не заливаете в сервер тонны логики?
Чем IIS по-вашему лучше MS SQL? Точно такой же сервер, только программируется на другом языке.
И вот язык программирования MS SQL удобен не всегда.
ANS>Это попытки нагрузить сервер чем-то кроме выполнения запросов это misconception. От нищеты и попытки на спичках экономить. Но сейчас потихоньку складывается такая ситуация, что там где есть смысл заливать логику в RDBM, там нет смысла пользоваться RDBM, а проще взять какой-то noSql и книжку Крокфорда (единственное, что сейчас мешает это незрелость). А вот там где преимущества RDBM встают в полный рост, там нет смысла логику заливать.
Непонятно, откуда вы это взяли. Я вам привожу пример запроса, который вы никаким noSQL не сделаете эффективнее. И никаким ORM вы его не сделаете эффективнее. SQL — это правильная, хорошая идея, не доведённая до конца.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ANS>>Ну, типа, вау. Но ты действительно не замечаешь разницы между внутренними механизмами сервера и тонами логики которые ты должен залить в сервер и там поддерживать? S>View — это не внутренний механизм сервера. Это чистой воды логика, которую я должен залить в сервер и там поддерживать. S>Stored Procedure — то же самое.
Так я и считаю, что в норме SP — это не нормально. В крайних случаях для хаков — да, а так — нет. View еще туда сюда. И то если это само приложение создаёт, а не какой-то мифический DBA.
S>Я вообще не очень понимаю, чего вы стесняетесь. Имея, допустим, сервер на ASP.NET, вы что, не заливаете в сервер тонны логики? S>Чем IIS по-вашему лучше MS SQL? Точно такой же сервер, только программируется на другом языке.
Разница хотя бы в том, что http-сервер это сродни сокет серверу. Никто сейчас не выносит код, который аксептит сокеты в отдельный сервер.
S> SQL — это правильная, хорошая идея, не доведённая до конца.
Если она так и не доведена до конца, то откуда удивление, что люди ищут альтернативу?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Так я и считаю, что в норме SP — это не нормально. В крайних случаях для хаков — да, а так — нет. View еще туда сюда. И то если это само приложение создаёт, а не какой-то мифический DBA.
Разница между этими понятиями достаточно условна. Есть жизненный цикл приложения, и он в общем случае одинаков.
ANS>Разница хотя бы в том, что http-сервер это сродни сокет серверу. Никто сейчас не выносит код, который аксептит сокеты в отдельный сервер.
Я вас не понимаю. Современный HTTP-сервер — это штука, которая быстро отдаёт файлы в сокет. Примерно так же, как SQL-сервер отдаёт select * from customers из таблицы.
В него можно вставить прослойку между файлами и сокетом. Это будет пользовательская логика, которую (о, ужас!) надо заливать в сервер и поддерживать её там.
S>> SQL — это правильная, хорошая идея, не доведённая до конца. ANS>Если она так и не доведена до конца, то откуда удивление, что люди ищут альтернативу?
Я удивляюсь не самому поиску альтернативы, а тому, где люди её ищут. То есть вместо дорабатывания SQL будем отказываться от него вовсе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ANS>>Разница хотя бы в том, что http-сервер это сродни сокет серверу. Никто сейчас не выносит код, который аксептит сокеты в отдельный сервер. S>Я вас не понимаю. Современный HTTP-сервер — это штука, которая быстро отдаёт файлы в сокет. Примерно так же, как SQL-сервер отдаёт select * from customers из таблицы.
Из SQL сервера можно запросит что-то сложнее чем "select * from customers", а из чистого http сервера — нет.
S>В него можно вставить прослойку между файлами и сокетом. Это будет пользовательская логика, которую (о, ужас!) надо заливать в сервер и поддерживать её там.
Разница в том, что логика размазывается по двум местам. При этом хранение логихи в БД имеет в добавок некую специфику. Но главное — должно быть разделение обязаностей.
S>>> SQL — это правильная, хорошая идея, не доведённая до конца. ANS>>Если она так и не доведена до конца, то откуда удивление, что люди ищут альтернативу? S>Я удивляюсь не самому поиску альтернативы, а тому, где люди её ищут. То есть вместо дорабатывания SQL будем отказываться от него вовсе.
Зачем отказываться. Ему место в самом низу. Там где его никто не видит.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Из SQL сервера можно запросит что-то сложнее чем "select * from customers", а из чистого http сервера — нет.
Зато из чистого HTTP сервера можно запросить if modified since, а из SQL — нет. Дальше что?
ANS>Разница в том, что логика размазывается по двум местам. При этом хранение логихи в БД имеет в добавок некую специфику. Но главное — должно быть разделение обязаностей.
Разделение обязанностей всегда есть.
ANS>Зачем отказываться. Ему место в самом низу. Там где его никто не видит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
На шарпе я не пишу. Все идеи взяты из GORM (Grails' object relational mapping).
Рассмотрим строку:
var documents = Manager.Get(objectsIds);
Если я правильно понимаю, то есть сущность InternalDisplacementDocument, объекты которой хранятся в базе данных, есть класс Manager и метод Get, который написан руками и возвращает список объектов InternalDisplacementDocument для заданных ключей.
Задача ORM хорошо подходит для использования DSL. Можно было бы написать:
var documents = InternalDisplacementDocument.findAllById(objectsIds);
И некоторым образом (например положить в определенный пакет) указать, что класс InternalDisplacementDocument является моделью, т.е. будет маппиться в БД.
Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его. Название поля Id, по которому нужно сделать запрос будет взято из названия метода. Префикс findAllBy используется для нахождения всех объектов, удовлетворяющих критерию, префикс findBy только для одного любого.
Аналогично:
// Найти все связанные операции по видам учета
IInventoryOperation[] operations = inv.GetInventoryOperations(
null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
if (InventoryOperation.findAllByAccountingKindAndOrderGreaterThan(relatedOperation.AccountingKind, relatedOperation.Order))
Что делает автоматически генерируемый метод findAllByAccountingKindAndOrderGreaterThan я думаю пояснений не требует.
таким образом, сокращается количество кода, написанного вручную.
Или, например, код
Manager.DeleteObject((IPersistedObject)invAfter);
Зачеркнут код, который не имеет отношения к бизнес-логике. DSL позволит записать:
invAfter.delete()
Необходимый минимум. И пусть уже обработчик DSL решает, как раскрыть delete метод.
Что касается остального кода, то, как уже правильно замечали, DSL это скорее описание архитектуры. Если получиться выделить отдельный свой логики, то для него можно будет разработать DSL. В данном примере скорее требуется декомпозиция
AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?
Здравствуйте, akochnev, Вы писали:
A>Задача ORM хорошо подходит для использования DSL. Можно было бы написать: A>
A>var documents = InternalDisplacementDocument.findAllById(objectsIds);
A>
A>И некоторым образом (например положить в определенный пакет) указать, что класс InternalDisplacementDocument является моделью, т.е. будет маппиться в БД.
Нет никакого класса InternalDisplacementDocument. Есть только интерфейс IInternalDisplacementDocument. И суть замены на статический метод (которому неясно как контекст передавать) мне непонятна.
A>Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его.
А зачем его генерировать?
A>Аналогично: A>
A>// Найти все связанные операции по видам учета
A>IInventoryOperation[] operations = inv.GetInventoryOperations(
A> null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
A>
A>Может быть заменено на: A>
A>IInventoryOperation[] operations = InventoryOperation.findAllByKindAndDocument(InternalDisplacement, doc)
A>
Не может. Внутри GetInventoryOperations бизнес-логика, а не тривиальный отбор по условию.
A>Что делает автоматически генерируемый метод findAllByAccountingKindAndOrderGreaterThan я думаю пояснений не требует. A>таким образом, сокращается количество кода, написанного вручную.
На 3 копейки.
A>Или, например, код A>
A>Manager.DeleteObject((IPersistedObject)invAfter);
A>
A>Зачеркнут код, который не имеет отношения к бизнес-логике. DSL позволит записать: A>
A>invAfter.delete()
A>
Ты серьезно думаешь, что это что то заметно улучшит?
A>Что касается остального кода, то, как уже правильно замечали, DSL это скорее описание архитектуры.
Ну, то есть, на самое интересное ответа и нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
A>>И некоторым образом (например положить в определенный пакет) указать, что класс InternalDisplacementDocument является моделью, т.е. будет маппиться в БД.
AVK>Нет никакого класса InternalDisplacementDocument. Есть только интерфейс IInternalDisplacementDocument. И суть замены на статический метод (которому неясно как контекст передавать) мне непонятна.
Не угадал название мало деталей...
В том то и дело, что это не статический метод — это DSL, который обозначает для модели InternalDisplacementDocument нужно выбрать все объекты для заданных objectsIds. Компилятор может развернуть этот DSL
var documents = Manager.Get(objectsIds);
если я правильно понимаю, то Manager не имеет отношения к бизнес логике, а является лишь механизмом реализации запроса. DSL призван скрыть особенности реализации. Если я пишу на уровне бизнес логики, то я ничего не знаю о сущности Manager. Мне просто нужно выбрать все документы по определенному набору id.
A>>Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его.
AVK>А зачем его генерировать?
Очевидно, чтобы не писать руками. Ведь метод Manager.Get(objectsIds) был написан вручную? Но решает то он типовую задачу. В приведенном по id также выбираются объекты IObjectLink из LinkManager. Предположу, что этот метод решает ту же задачу. Его также можно автоматически генерировать по DSL типа:
A>>// Найти все связанные операции по видам учета
A>>IInventoryOperation[] operations = inv.GetInventoryOperations(
A>> null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
A>>
AVK>Не может. Внутри GetInventoryOperations бизнес-логика, а не тривиальный отбор по условию.
Понял.
A>>Что делает автоматически генерируемый метод findAllByAccountingKindAndOrderGreaterThan я думаю пояснений не требует. A>>таким образом, сокращается количество кода, написанного вручную.
AVK>На 3 копейки.
Ок. Наверное, это зависит от специфики приложения. В тех, приложениях, которые я видел, подобные простые запросы все же использовались довольно часто (как в составе более сложных, так и по отдельности). Возможность не отвлекаться на реализацию таких методов (а также сопутствующей архитектуры) позволяла сразу приступать к реализации требуемой функциональности, снижая общие затраты на разработку.
A>>Или, например, код A>>
A>>Зачеркнут код, который не имеет отношения к бизнес-логике. DSL позволит записать: A>>
A>>invAfter.delete()
A>>
AVK>Ты серьезно думаешь, что это что то заметно улучшит?
Не претендуя на абсолютную истину, думаю, что да, улучшит.
DSL не является серебряной пулей. Сам по себе он не способен уменьшить сложность бизнес логики. Он призван отделить именно "бизнес-логику" от деталей реализации, не имеющих к ней отношение.
Я думаю, что ты не будешь спорить, что в данном примере бизнес логика смешивается с деталями ее имплементации. И не будешь спорить, что вынесение запроса в слой доступа к данным в Manager.Get(objectsIds) лучше, чем реализация его по месту использования. Перемешивание SQl запросов и бизнес логики ведь считается плохой практикой. DSL это просто еще один шаг в разделении бизнес логики и остального кода.
A>>Что касается остального кода, то, как уже правильно замечали, DSL это скорее описание архитектуры.
AVK>Ну, то есть, на самое интересное ответа и нет.
Я не считаю, что использование DSL именно этот кусок кода сделает значительно лучше/понятнее.
Я всего лишь попытался привести примеры, в которых использование DSL упрощает интерфейс и избавляет от ручного написания некоторой части кода.
Здравствуйте, akochnev, Вы писали:
A>В том то и дело, что это не статический метод — это DSL, который обозначает для модели InternalDisplacementDocument нужно выбрать все объекты для заданных objectsIds. Компилятор может развернуть этот DSL A>
A>var documents = Manager.Get(objectsIds);
A>
Ну и смысл?
A> DSL призван скрыть особенности реализации.
Это какая то уж очень причудливая абстракция. Принципиально замена Manager на OLaLa ничего не меняет.
A>>>Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его.
AVK>>А зачем его генерировать? A>Очевидно, чтобы не писать руками.
Так его не надо писать руками Он уже написан.
A> Ведь метод Manager.Get(objectsIds) был написан вручную?
Ну да, один раз, причем в платформе.
A> Но решает то он типовую задачу.
Так зачем еще один метод решения типовой задачи?
A> В приведенном по id также выбираются объекты IObjectLink из LinkManager. Предположу, что этот метод решает ту же задачу.
Нет.
A> Его также можно автоматически генерировать по DSL типа:
Генерация метода, который внутри вызывает ровно один метод с той же сигнатурой — практический смысл сего действа мне по прежнему непонятен.
AVK>>На 3 копейки. A>Ок. Наверное, это зависит от специфики приложения. В тех, приложениях, которые я видел, подобные простые запросы все же использовались довольно часто
Понимаешь, нет в приведенном коде никаких таких запросов. Есть просто логика. Да, перебор можно как то упростить, но, в данном случае, все это прекрасно переписывается на linq без каких либо спецDSL. А вот тот код, который у меня наибольший интерес вызывает — вот его ты рассматривать не хочешь. И оно понятно почему — задачка то куда сложнее.
AVK>>Ты серьезно думаешь, что это что то заметно улучшит?
A>Не претендуя на абсолютную истину, думаю, что да, улучшит.
Что именно?
A>DSL не является серебряной пулей. Сам по себе он не способен уменьшить сложность бизнес логики. Он призван отделить именно "бизнес-логику" от деталей реализации, не имеющих к ней отношение.
Думаю, многие с тобой тут не согласятся. Для отделения логики от реализации достаточно средств языка, DSL для этого — как из пушки по воробьям.
A>Я думаю, что ты не будешь спорить, что в данном примере бизнес логика смешивается с деталями ее имплементации.
Буду. Нет в ней никаких деталей импл..., убил бы реализации. Manager, который тебя так беспокоит — абстрактный интерфейс, фабрика бизнес-объектов. Никакого смысла от него избавляться нет. А LinkManager — вообще часть бизнес-логики, а не часть платформы.
AVK>>Ну, то есть, на самое интересное ответа и нет. A>Я не считаю, что использование DSL именно этот кусок кода сделает значительно лучше/понятнее.
Ну, собственно, этого достаточно.
A>Я всего лишь попытался привести примеры, в которых использование DSL упрощает интерфейс и избавляет от ручного написания некоторой части кода.
Удобные примеры я и сам могу привести сколько хочешь (и даже приводил здесь). Вопрос в примерах неудобных, потому что название топика позиционирует DSL как универсальный всемогутер.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
N>>Хорошо, я теперь буду знать, что "я бы не назвал белое белым" является адекватным выражением твоей точки зрения. Учтём это в спорах об уездном городе языке N и других горячих темах VD>Ты занимаешься демагогией. Он же привел отличный пример. Монеты ни разу не компакт-диски, не смотря на то, что они несомненно компактные, и несомненно диски.
Это отличный пример, если заранее поверить в правильность его выводов, но если нет, то он натягивается на что угодно и служит разве что обоснованием того, что надо вначале разобраться, что и как называть. А он не разобрался, или намеренно выделил только самый частный случай.
VD>Причем дело доходит до обсурда. VD>Один под ДСЛ-нем начинает понимать все языки программирования которые кто-то прикрутил к какому то приложению (в том числе и жабаскрпит в броузерах). VD>Другой называет ДСЛ-ем наличие модели в приложении. VD>Третий видит ДСЛ в любом АПИ.
А ты думаешь, зачем я предложил несколько уровней "вложенности" понятий? Ты в принципе не найдёшь общего подхода для всех, и каждая из этих точек зрения имеет свой смысл и своё основание.
VD>Фаулер не рассматривает отвлеченных тем. Он рассматривает то, что он сам считает (и называет) ДСЛ-ями. VD>По сему он привел ряд критериев которые позволяют назвать язык ДСЛ-ем (по его мнению). Я сними согласен. VD>Но к сожалению, они неформальны. Вот они: VD>Предметно(ориентированный язык (сущ.) — это язык программирования с ограниченными выразительными возможностями, ориентированный на некую конкретную предметную область.
У тебя в цитатах какие-то странные символы, выглядят квадратами или цепочками квадратов.
Определение Фаулера, насколько я вижу, близко к самому жёсткому из моих вариантов ("ограничен").
VD>• Природа языка. DSL является языком программирования и как таковой должен давать ощущение свободы выразительных возможностей, проистекающее не только из отдельных выражений, но и из способа их соединения.
Нужно ли было давать это в критерии? Это совсем неформализуемый признак.
VD>Обратите внимание на то, что ориентированность на предметную область оказалась последней в списке и является лишь следствием ограниченных выразительных возможностей.
Верно, самый жёсткий — ограниченный — вариант или будет специализированным (тогда у него есть необходимые признаки для хоть какой-то успешности), или он дохнет. Но такое определение заведомо отрезает, например, язык 1C. С другой стороны, почему тогда это domain *specific*, а не domain *restricted* language?
VD>Его мысль в том, что наличие одного из условий еще не делает язык ДСЛ-ем. Нужно сочетание факторов. VD>И я с этим категорически согласен.
N>>Прикидка определения каждого из этих понятий: N>>* ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию N>>* специализированность — адаптирован в целом (в общих принципах) под названную цель N>>* специфичность — реализация запросов за пределами названной цели заметно усложнена N>>* ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели VD>Опять какая-то каша. Ориентированность, специализированность и специфичность — это все из одной оперы.
Нет. Это последовательно сжимающиеся условия, каждое следующее всё более ограничено по сравнению с предыдущим.
VD>Твои критерии вообще никуда не годятся. Критерии фаулера — годятся.
Критерий Фаулера — только мой случай ограниченности, с автоматически потянувшимися за ним остальными ограничениями. Мои позволяют назвать и остальные типичные случаи.
Например, C — *специализирован* на системное программирование, а Fortran — на численные расчёты, хотя ни один из них не *ограничен* и относительно слабо *специфичен*. Если пользоваться критериями Фаулера, ты их в принципе не различишь — они все будут в пределах одного "это не DSL, а что за птица — хрен его знает, мы не умеем такое различать". Я же могу назвать в этих терминах, чем они отличаются, и указать конкретные признаки.
VD>Язык с неограниченной выразительностью ДСЛ-ем быть не может, согласно этим критериям. VD>Таким образом полные по тьюрингу языки вполне могут быть ДСЛ-ями, если их тьюринг-полнота не дате писать что попало в любой области.
С этим полностью согласен.
VD>Зато язык не полный по тьюрингу и ориентированный на конкретную задачу — это уже точно ДСЛ.
А вот тут уже нет. Во-первых, не понятно в твоём случае, что значит "ориентирован". Во-вторых, отсутствие тьюринг-полноты не означает отсутствие средств для совсем другой цели. Про DSL можно говорить только тогда, когда мы определяем этот домен и соответствие ему; но язык может соответствовать нескольким доменам. Например, HTML — это что? Hypertext markup language? Тогда зачем в нём картинки, скрипты, CSS?
VD>И вообще, важно разделять ориентацию на предметную область, и ориентацию на задачу. ДСЛ ориентирован на одру конкретную задачу,
Точно одну? См. выше про HTML.
VD> а не на предметную область в широком понимании этого термина. Скажем императивный язык для бухгалтерии — это не ДСЛ. А вот язык запросов к документам — ДСЛ.
Мне это не нравится в первую очередь из-за того, что у тебя термин DSL оторвался от породившего его языка. Слово specific обычно не означает пригодность и ограниченность только для данной цели; я специально глянул в словарь — сказано "related to one thing and not others", но это related, а не более жёсткое отношение. Это к тому, что внедрение такого понимания, по крайней мере в англоязычной среде, будет сопровождаться насилием над понятием.
То, что ты имеешь в виду, должно быть DTL или DRL. Ибо targeted, restricted.
N>>Во-во. Проблему он почувствовал, но выразить не супел. VD>Он то сумел. Просто кто-то кобенится и не хочет понять сказанного.
Админ, исцелись сам.
VD>Я бы предпочел четкую терминалогию, и четкое разделение понятий. Язык 1Эс нужно отличать как от универсальных ЯОН-ов, так и от ДСЛ-ей. Это самостоятельный класс языков.
Верно. Это DTL. А определение Фаулера — это DRL.
VD>В том то и дело, что у нас дисскурссия возникает даже по крайним случаям. Есть не мало упертых товарищей которые называют ДСЛ-ями ВБА.
Я согласен. Это DSL, а конкретно — Domain Specialized Language.
VD> А кое-то (весьма не глупый) вообще дофилософствовался до того, что подменил понятие "уровень языка" понятием "ДСЛ", а ДСЛ в его словах это любой язык относительно языка более низкого уровня.
Читай внимательно — это неизбежный, но вторичный признак.
VD>Такие "знания" и такая терминология не дает возможность продуктивно обсуждать данную область.
Даёт. А вот если ограничиваться только одной жёсткой границей по Фаулеру — тогда обсуждения действительно не получится.
VD>Так что нужно сделать одно из двух: VD>1. Ограничить определение термина ДСЛ выделив независимые понятия в отдельные понятия и дав им названия (введя термины). VD>2. Придумать новые термины для подтипов ДСЛ-ей, если уж не удается прийти к консенсусу в п.1.
Это я и пытаюсь сделать.
VD>Вот регекспы и ВБА по-твоему ДСЛ-и?
Первое — domain restricted, второе — domain specialized.
VD>Если, да, то нужно придумать новые термины для различения этих подвидов ДСЛ-ей.
См. выше.
VD>Если нет, то для ВБА нужно придумать отдельный термин, а ДСЛ-ем называть только регекспы.
VD>Для ВБА термин есть — скриповый язык встроенный в хост-приложение. А как нажвать класс ДСЛ-ей в который входят регексы, SQL и т.п.?
Здравствуйте, VladD2, Вы писали:
VD>Так что остается только одна проблема. Как заставить неверующих Фом хотя бы взглянуть на то, что у нас получается. Я уже не говорю об использовании.
А у тебя всегда ктото другой виноват. Твой вопрос абсолютно неконструктивный, ибо фактически ты признаешь что эти неверующие фомы определяют ваш успех.
Более конструктивно будет задаться вопросами
Кто есть ваша ЦА ?
Что ей нужно ?
Еак донести до ЦА ваши разработки ?
Вобщем играйте в свои дсл для роутинга урлов, пермишнов и тд и тд.
Здравствуйте, WolfHound, Вы писали:
V>>Дык, Пратт его показал в каком-то махровом 70-м году и никто ни кого не послал. Ведь Дракон — лишь одна из мн-ва работ на эту тему, но почему-то стала более популярной... Не насильно же... WH>Насильно. Ибо в институтах только это направление и дают.
Ты вообще хорошо понимаешь, что такое система образования, какие у нее задачи и какой критерий отбора материала для обучения ?
Здравствуйте, Ikemefula, Вы писали:
I>Еак донести до ЦА ваши разработки ?
Для Фомы — это бессмысленно. Вот до тебя я вроде информацию донес, но что толку то? У тебя же вера в том, что тебя обманывают. Ты же проверять не будешь. А что тебе на словах можно доказать?
I>Вобщем играйте в свои дсл для роутинга урлов, пермишнов и тд и тд.
Ага. И вам приятно лясы поточить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
WH>>Насильно. Ибо в институтах только это направление и дают. I>Ты вообще хорошо понимаешь, что такое система образования, какие у нее задачи и
Ее задача подготовить адекватных специалистов.
Но она с этим не справляется.
Ибо когда молодой специалист приходит на производство ему говорят, забудь все чему тебя учили и начинают учить по новой.
I>какой критерий отбора материала для обучения ?
По желанию левой пятки ответственных за подбор материала.
Но так как они давно оторвались от реальности, они не могут подобрать нормальный материал, даже если захотят.
Но самое скверное, что им часто пофигу. Что-то читают. Получают деньги. И ладно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
ANS>>Разница в том, что логика размазывается по двум местам. AVK>Это всего лишь вопрос деплоймента. И никто не мешает сделать деплоймент полностью автоматическим.
Вторая разница в том, что изменение процедур в БД изменяет состояние. И обычно это несколько более сложная операция чем копирование новых файлов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Вторая разница в том, что изменение процедур в БД изменяет состояние.
Какое состояние и чем это плохо?
ANS> И обычно это несколько более сложная операция чем копирование новых файлов.
Разница непринципиальна. В больших системах все равно процедура деплоймента нетривиальна — структуру БД ту же надо привести в соответствие. На этом фоне апдейт хранимок — просто ерунда.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
мало деталей...
Он уже написан.
