Здравствуйте, Jack128, Вы писали:

J>db.Users.Insert(() => new User { Name = "Новый юзер" });
J>Это C# + BLToolkit

Да, про BLT знаю и, кстати, предполагал именно его использовать для доступа. Вопрос тут скорее для того, что может быть кто-то придумает нечто полезное и интересное с использованием макросов.

Здравствуйте, ionoy, Вы писали:

I>Вполне устраивает. Меня больше интересуют инфраструктурные вопросы, как генерировать базу и прочее.
I>Может у кого-то возникнет интересная идея.

У Ziaw есть движок миграций. Можно для начала его приспособить. Но лично я бы предпочел подход от модели (что МС называют код-фирст), когда описывается модель в виде некоторого ДСЛ-я и уже по ней генерируется БД и миграции.

Здравствуйте, ionoy, Вы писали:

I>Здравствуйте, VladD2, Вы писали:

VD>>А чем использование линка не устраивает?

I>Вполне устраивает. Меня больше интересуют инфраструктурные вопросы, как генерировать базу и прочее.
I>Может у кого-то возникнет интересная идея.

Позволю процитировать один свой мысль по этому поводу

Объектная модель мне по многим причинам кажется лучше, при том, что если кто-то считает лучшей реляционную,
это должно быть поддержано и продумано. Очень желательно иметь технику связи с базами данных, независимую от
используемой СУБД и прозрачную для кода использования. Это должно выглядеть так, что вроде никакой базы нет,
т. е. код не нуждается в переделках не только при переходе от одной СУБД к другой, и при переходе к использованию базы.
То, что это возможно и как примерно выглядит, можно посмотреть в Zdb, приближение которой к полному Zen упирается в текущие ограничения N.

выглядеть это должно так:

//using zdb
//using no_db
using mongo_db

[Ndb] //все, что требуется,-  добавить в рутовый класс для работы с Ndb-схемами
class x
    d : NDict[int, string]
    l : NList[x]

class u: x
   k: int
   lk : NList[int]    

class i : x
  j : NHash[myclass]

Nlist, NDict, NHash ... — макротипы стандартной Nid библиотеки, которые в зависимости от активированной схемы разворачиваются
либо в стандартные.Net/Java коллекции, либо специализированные для mongo или любой другой СУБД, для которой написан Ndb метаконнектор.
Код связи и обслуживания генерируется при компиляции (см Zdb), а работа с данными одинакова и прозрачна для всех поддерживаемых Ndb.
Уверен, что это strongly must have killer-фича, наглядно показывающая любому скептику, что мы не просто так тут собрались.

и здесь реализация реализация этого для случая встроенной бд.

ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора

Здравствуйте, _Claus_, Вы писали:

_C_>ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора

Поднял тему — развивай

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, _Claus_, Вы писали:

_C_>>ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора

_NN>Поднял тему — развивай

вам хочется песен — их есть у меня!

уже это показывал здесь — реакции не было. вообще. подожду думаю лет пять. обычно потом принимают как родное.

что непонятно или расшифровать — спрашивайте.

Здравствуйте, Jack128, Вы писали:

J>db.Users.Insert(() => new User { Name = "Новый юзер" });
J>Это C# + BLToolkit

Уж на Немерле можно было бы и более приличный синтаксис сделать. Insert/Update/Delete в стиле SQL были бы очень приятной фичей.

_C_>что непонятно или расшифровать — спрашивайте.

для тех, кому лень читать что попало — основная мысль:

макротипы — это штука, которая стирает (прячет) грань между простым кодом и макросом.
работая с макротипом(и), как с обычным классом, мы в итоге получаем любой согласованный везде код, количество и сложность которого ограничена только нашей фантазией.
имея макротипы для бд или гуя мы перекомпилировав с одним другим юсингом получим высокооптимальный код для заказанной платформы.
со всеми связками, хмлями и прочей лабудой, нужной для платформозависимого кода, и о которой разумному программисту и знать не надо.

Здравствуйте, _Claus_, Вы писали:

_C_>> уже это показывал здесь — реакции не было. вообще. подожду думаю лет пять. обычно потом принимают как родное.
Так мало поддержки, нужно еще и реализовывать.

_C_>макротипы — это штука, которая стирает (прячет) грань между простым кодом и макросом.
_C_>работая с макротипом(и), как с обычным классом, мы в итоге получаем любой согласованный везде код, количество и сложность которого ограничена только нашей фантазией.
_C_>имея макротипы для бд или гуя мы перекомпилировав с одним другим юсингом получим высокооптимальный код для заказанной платформы.
_C_>со всеми связками, хмлями и прочей лабудой, нужной для платформозависимого кода, и о которой разумному программисту и знать не надо.

Теперь ясно.
Я бы добавил в желания еще поддержку макрометодов.

Здравствуйте, _NN_, Вы писали:

Можно пример макротипа? (с кодом) И макрометода....

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, _NN_, Вы писали:

А>Можно пример макротипа? (с кодом) И макрометода....

http://rsdn.ru/forum/nemerle/4631408.1.aspx

Автор:
Дата: 23.02.12

http://rsdn.ru/forum/nemerle/4157150.1.aspx

Автор: hi_octane
Дата: 14.02.11

http://rsdn.ru/forum/nemerle/4297853.1.aspx

Автор: hi_octane
Дата: 03.06.11

и далее по ветке

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, _Claus_, Вы писали:

_C_>>> уже это показывал здесь — реакции не было. вообще. подожду думаю лет пять. обычно потом принимают как родное.
_NN>Так мало поддержки, нужно еще и реализовывать.
попробую. после парсера.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, _NN_, Вы писали:

А>Можно пример макротипа? (с кодом) И макрометода....

using ProtoScheme
 //наследование от типа есть считывание шаблона
 //и создание заглушек по умолчанию, в точности возвращающих то, что описано 
 macrotype NxList[T] : List[T] {}
   //public Contains(x: T): bool такое создается автоматом
   //  <[Contains(x)]>
   
   public SubListBy(range: T): NxList[T] //новый макрометод макротипа
     <[ 
         def range = IndexOf(range); //List.IndexOf

         NxList(this.Range(0, range));
      ]>

using NoScheme
 //нас все устраивает по имеющемуся умолчанию
 macrotype NxList[T] : ProtoScheme.NxList[T] {}

//другой файл
using DBScheme
 macrotype NxList[T] : ProtoScheme.NxList[T]
    //переопределяем
    public this()
      <[ DbBigList[T]() ]>

    //переопределяем
    public SubListBy(range: T): NxList[T]
      //что то считаем 
      <[и тут]>

    //переопределяем
    public Contains(x: T): bool
      <[  def data4qyery = нудный_код();
          ... 
          this.QueryContains(что_насчитали_выше)
       ]> 

    ... для остальных методов, определенный у NxList(List)

имеет две модели генерации — NoScheme, DBScheme

они включают в себя идентичные группы объектов, которые для пользователя ведут себя одинаково.
в процессе компиляции юсинг модели в корне меняет код, который получается в итоге.
в данном случае при NoScheme использование NxList порождает код стандартный контейнеров, при DBScheme — работу с удаленной базой.
без изменений кода. в процессе генерации может порождаться xml, javascript, бог знает что еще. прозрачно и незаметно.

Здравствуйте, ionoy, Вы писали:

I>Да, про BLT знаю и, кстати, предполагал именно его использовать для доступа.

C blt, кстати, та же проблема, что и с nemerle.dll, зависимость от конкретной версии. Если Nemerle.Web еще можно включить в инсталятор nemerle и она всегда будет ссылаться на доступную версию nemerle.dll, то ее зависимость от конкретного тулкита будет уже довольно печальным фактом.

Здравствуйте, VladD2, Вы писали:
VD>У Ziaw есть движок миграций. Можно для начала его приспособить. Но лично я бы предпочел подход от модели (что МС называют код-фирст), когда описывается модель в виде некоторого ДСЛ-я и уже по ней генерируется БД и миграции.

Главное, что мне нравилось в nHibernate, это как раз-таки автоматическая генерация и обновление базы по модели. Наверное, что-то вроде этого и надо будет прикрутить, например взять из EF. Если кто знает где ещё это реализовано, предлагайте.

Здравствуйте, Ziaw, Вы писали:
Z>C blt, кстати, та же проблема, что и с nemerle.dll, зависимость от конкретной версии. Если Nemerle.Web еще можно включить в инсталятор nemerle и она всегда будет ссылаться на доступную версию nemerle.dll, то ее зависимость от конкретного тулкита будет уже довольно печальным фактом.
Есть какие-то идеи как это решить?

Здравствуйте, VladD2, Вы писали:
VD>Уж на Немерле можно было бы и более приличный синтаксис сделать. Insert/Update/Delete в стиле SQL были бы очень приятной фичей.

Это наверное вопрос предпочтений, но я тот же линк с SQL синтаксисом использую только в особо запутаных случаях.
А подобную фичу кто-нибудь мог бы реализовать отдельным макросом, не зависящим от фреймворка или чего-то ещё.
Просто должны быть подстановки по договорённости select -> Select(), и возможность их оверрайдить через макросы уровня сборки.

Здравствуйте, ionoy, Вы писали:

Итак благодаря компиляции C# файлов можно использовать даже C# для ViewModel.
На данный момент Nemerle требуется только для самого метода View.

Код и рабочий пример можно увидеть на тестовом сайте: http://user1663.netfx45lab.discountasp.net/

Здравствуйте, ionoy, Вы писали:

I>Главное, что мне нравилось в nHibernate, это как раз-таки автоматическая генерация и обновление базы по модели. Наверное, что-то вроде этого и надо будет прикрутить, например взять из EF. Если кто знает где ещё это реализовано, предлагайте.

EF сюда тащить — это перебор.

Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД.

Вообщем — это большая отдельная задача и я бы посоветовал не смешивать их.

Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД.

Здравствуйте, VladD2, Вы писали:

VD>Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД.
А еще лучше скооперироваться с IT'ом. И сделать крутой BLT для немерла.

Здравствуйте, VladD2, Вы писали:

VD>Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД.
Почему тяжело? Обновлять базу данных "вперёд" как раз легко. Насчёт отката не уверен, никогда не приходилось.