не уважает сообщество sql и тем более ms, скорей всего без вариантов пока

Ну для MySQL, например, есть много вменяемых ORM. Для MSSQL единственное, что нашлось - голый драйвер для голых запросов.

node.js - модно и ынтырпрайзно

Вот это ты пошутил, ай молодец. Правильно, технологии так и надо выбирать, с юмором!

node.js
Всё неблокирующееся и на асинхронных callback'ах.

готовь вазелин

(база - MSSQL, обновляется существующим приложением на .NET).

Чем не устраивает .NET ? Не хватает острых очучений чтоли раз на node.js засматриваетесь?

http://snapframework.com/

Тоже пилю похожий проектик, у меня пока расклад такой
- ORM для MSSQL не знаю, для MySQL юзаю Sequelize
- для чисто REST'а есть какие-то модули типа restify, но мне оно как-то не понравилось, использую Express. В планах его выпилить, т.к. много в нем лишнего, но пока работает и жрать не просит
- по дизайну API - я руководствовался этими материалами
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
http://habrahabr.ru/post/181988/
http://info.apigee.com/Portals/62317/docs/web api.pdf

Модель программирования по началу очень выносит мозг, будь готов к критическим рейтам WTF/sec

а потом расчехляй какой-то iced-coffee-script и живи припеваючи

Посмотрите библиотеки lodash (underscore) и express. Если сервисы мелкие - должно хватить для типовых серверных задач. Если нужен навороченный менеджер ассетов - mincer.

С мссиквелом сами. Поищите модули на wiki нодовского репа и сайте npm. Из ORM, внушающих доверия, знаю только монгуз под монгу. Остальное либо мутное, либо DSL.

Если уже есть приложение на дотнете, на нём и пиши, а не плоди технологии. Наверняка и часть кода модно будет переиспользовать.

Раз уж ты такой трендовый пацан, то почему не Cassandra, Riak? А CouchDB/MongoDB, так там же вообще твой любимый JS во все поля?

Базу трогать нельзя. В ней вся логика приложения (на stored-процедурах). Опять же существующее приложение, работающее с ней - это огромный legacy-монстр на WinForms.

Но, наверное, и правда послушаюсь совета товарищей и останусь на .NET.

Нода может быть хороша в двух случаях. а) для домашних поделок б) ты уже эксперт по ноде с 5 проектами за плечами и понимаешь что она подходит для твоей задачи.

Я думаю что в данной ситуации ни то, ни другое

Это не одна из технологий «бери - не промахнешься» или «no one get's fired for using ...»

Node.js я бы рекомендовал либо 1) для single page application, в этом случае сейчас набирает обороты MEAN стак (MongoDb, Express, Angular.js, Node.js). Под SQL есть Sequelizе, но он ещё далёк от совершенства. 2) для API, real-time web в связке с Socket.io

В любом случае надо сначала научиться писать грамотно код, разобраться с future, promise, fibers и прочими штуками. + Купить мак и свитер.

Если очень хочешь попробовать новый ощущений, рекомендую Python! Просто учится, полезно для широкого круга навыков. Смотрим на Flask - просто прозрачно, достаточно стабильно. Документация чёткая, всё как в сказке! Прикручиваем SQLAlchemy и будет тебе коннект с MSSQL.

Это конечно «крутые» ORMки, которые умеют только MySQL. Я всегда считал, что одна из задач ORMок — это абстрагирование от типа используемой СУБД в том числе.

Задача ORM - обеспечить конвертацию между объектной моделью данных и реляционной моделью данных.

Задача ORM - обеспечить конвертацию между объектной моделью данных и реляционной моделью данных.

Буквоедствуй дальше с определениями на здоровье, дружище, меня-то только зачем трогать? Я исхожу из текущей практической ситуации среди уже существующих проектов.

По делу: почему-то любая человеческая ORM (вне зависимости от конкретного типа, AR-ли или DataMapper полноценный) имеет ещё в комплекте и нормальный DBAL (database abstraction layer), который позволяет полностью абстрагироваться от типа РСУБД. SQLAlchemy или Doctrine2 вполне годятся под определение «нормальная, человеческая» (проблем ни у той, ни у другой с MSSQL нет).

То, что ORMки в Node.js этого не умеют/не имеют — это просто гигантский минус в отношении юзабилити, вне зависимости от того, что написано в определениях тех или иных понятиях (понятие ORM в данном случае).

как ты предлагаешь это реализовать, если все БД имеют свои плюшки и специфику, которую надо учитывать? нельзя просто взять и написать ORM, которая одинаково хорошо будет работать с любой СУБД, это реализуется отдельными модулями в составе ORM. Нода - проект сравнительно молодой и активно развивающийся, на это обращают внимание любые обзоры, говоря «будте готовы, что многое еще не написано, а то, что написано, может потребовать доработки напильником. Это естественный процесс»

Конкретные проекты, как правило, пилятся под конкретную СУБД. Только «коробочные» и общедоступные опенсорсные продукты умеют работать с разными. Но такие проекты на node.js всё равно не пишут.

ORM не избавляет от необходимости помнить о базе и о конкретных заморочках выбранной СУБД. Мне вот приходится особым образом конструировать некоторые особо критичные к производительности запросы querydsl-jpa, чтобы генерируемый SQL отрабатывал не за полчаса и использовал индексы, а не временные таблицы с файлсортом.

как ты предлагаешь это реализовать, если все БД имеют свои плюшки и специфику, которую надо учитывать?

Молча. Примеры:

https://github.com/doctrine/dbal/tree/master/lib/Doctrine/DBAL/Driver
https://github.com/yiisoft/yii2/tree/master/framework/yii/db

нельзя просто взять и написать ORM, которая одинаково хорошо будет работать с любой СУБД, это реализуется отдельными модулями в составе ORM

Ну это капитанство. :-) Выше накидал примеров, могу ещё вагон примеров накидать.

Нода - проект сравнительно молодой и активно развивающийся, на это обращают внимание любые обзоры, говоря «будте готовы, что многое еще не написано, а то, что написано, может потребовать доработки напильником. Это естественный процесс»

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

Никаким enterprise и production ready в Node.js и не пахнет без этого.

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

Из-за асинхронности тут «всё не как у людей». Готовые фреймворки с блокирующими вызовами нельзя просто взять и адаптировать.

Конкретные проекты, как правило, пилятся под конкретную СУБД. Только «коробочные» и общедоступные опенсорсные продукты умеют работать с разными. Но такие проекты на node.js всё равно не пишут.

Мы сейчас разве конкретный проект тут обсуждаем? Вроде бы Node.js обсуждается, а это вполне себе опенсорсный и общедоступный проект.

ORM не избавляет от необходимости помнить о базе и о конкретных заморочках выбранной СУБД.

Избавляет, по-крайней мере должна (в нормальных фреймворках и платформах). Вот ещё пример того, как это решается по нормальному в нижележащем абстрактном интерфейсе для работы с БД: http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/queryhql.html

И что? Про JPQL (и про его проприетарные и непортируемые хибернейтовские расширения) я знаю. Только он не избавляет от необходимости думать о сгенерированном SQL.

Напишешь чуть не так - СУБД проигнорирует индекс, и запрос будет выполняться не 30 миллисекунд, а 30 секунд. В лучшем случае.

И что? Про JPQL (и про его проприетарные и непортируемые хибернейтовские расширения) я знаю. Только он не избавляет от необходимости думать о сгенерированном SQL.

Напишешь чуть не так - СУБД проигнорирует индекс, и запрос будет выполняться не 30 миллисекунд, а 30 секунд. В лучшем случае.

Мы видимо немного по-разному понимаем суть определения «не нужно думать о конкретной СУБД». Так-то генерируемые ORMкой запросы я тоже абсолютно всегда смотрю в логах и в зависимости от них так или иначе кручу ORMку и запросы в ней.

попробуй рельсы, сам как-то делал небольшой проект под существующую базу mssql

http://railsinstaller.org/
http://www.rusrails.ru/

в помощь

class Oceane < ActiveRecord::Base
	set_table_name "Oceanes"

	#set_primary_key(nil)
    set_primary_key "ID"   	# it can be accessed in contreller as "id" (lower case)
							# https://gist.github.com/937739
							# rizenine commented June 14, 2011
							# Why is this 'self.id' and not 'self.uuid'? "self.id = UUIDTools::UUID.random_create.to_s"
							# Askegg commented June 15, 2011
							# @rizenine
							# Because the primary key has been switched to uuid by set_primary_key 'uuid'. This renders the id column in the database redundant.

							

# set_primary_key(value = nil, &block)

# Sets the name of the primary key column to use to the given value, or (if the value is nil or false) to the value returned by the given block.

  # class Project < ActiveRecord::Base
    # set_primary_key "sysid"
  # end

# This method is also aliased as primary_key=

# Source: hide | on GitHub

    # # File activerecord/lib/active_record/attribute_methods/primary_key.rb, line 48
# 48:         def set_primary_key(value = nil, &block)
# 49:           @quoted_primary_key = nil
# 50:           define_attr_method :primary_key, value, &block
# 51:         end




	alias_attribute :name, "Ocean"
	# new stops workin with it
	# show stops workin withOUT it
	
	attr_accessible :name
	
	
end
#http://jonathanhui.com/ruby-rails-3-model-working-legacy-database
#class Member < ActiveRecord::Base
#  set_primary_key :member_id
#end