ПарамонЕсли ты про автогенерацию дата модели в EF, то сама по себе она ничего не стоит.
В случае использовании не ORM подхода тебе придется писать руками этот код и так же руками маппить его на свои классы. Или еще хуже - оперировать датасетами в прикладном коде. Поэтому, автогенерация дата модели - это громадная экономия трудозатрат программиста.

ПарамонРеальные модели состоят из совокупности разных таблиц, и нужно руками делать целый слой dto, и мапинга, что бы придерживаться паттерна.
С случае не ORM подхода точно так же придется писать эти DTO и маппинги, всё тоже самое.

маштабируемыйну да, ну да... так значит ты работал с коучдб 14278356 и она тебе понравилась...
особенно, как там реализован рест апи, полагаю

ппц... клоун...

Ух, с какой радостью ты решил вбросить этот пост 14279394 , но когда тебя немного обламали и сказали, что это практически тоже самое - радость сразу поубавилась. Я тебе более скажу: в этих базах принципиально одинаковый движок и .NET объектная модель. Так что для моего IRepository было фиолетово, какой именно там куч прикручен - db или database. Клоуна видишь в зеркале, двоешник.

ПарамонМСУС случае не ORM подхода точно так же придется писать эти DTO и маппинги, всё тоже самое.
Если я не буду использовать репозиторий, а извлекать данные и работать с ними в сервисном слое, это снизит количество дто и кода маппинга. Зачем мне целый слой абстракции ради crud?
Так даже студенты не пишут. Абстракция от данных в отдельном слое - это матчасть, которая пишется даже в application architecture guide. При твоем подходе связность кода максимальная. Читай про "вонь от кода" и закон Деметры тут: http://msdn.microsoft.com/ru-ru/magazine/cc947917.aspx
Про повторное использование этого дополнительного слоя в других проектах рассказывать?

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


Предлагаю не останавливаться на этом, а почитать документацию:
http://www.couchbase.com/couchbase-vs-couchdb The strong influence of Apache CouchDB on the storage approach means that Couchbase also uses an append-only file format and fundamentally the same approach to indexing and querying as Apache CouchDB; it just extends and optimizes it to the distributed case. Finally, Apache CouchDB replication technology is the underlying technology for Couchbase cross datacenter replication.

маштабируемыйтак тебе понравилась та .NET библа, которая обрабатывает couchbase!!!
Как до тебя быстро доходит, жирафы отдыхают... Помимо .NET модели, мне реально понравилась скорость IO, которая на порядки выше, чем у реляционных БД.

маштабируемыйа за РЕСТ АПИ ты краем уха зацепился?!!! ;)))
Я что-то про RESTAPI говорил в разрезе куч? То, что мне нужно было от этой БД, я написал постом выше.

Парамонна практике повторное использование работает отлично в рамках одного приложения, и сервисный слой хватает для сего за глаза.
Ты просто не работал с такими проектами, поэтому не нужно говорить про "практику". У меня даже на простецком сайте codearticles.ru дата слой используется в трех проектах: сам сайт, проект рассылки уведомлений и проект полнотекстового индекса.

ПарамонДругие интерфесы подключенные в проекту, зачастую требуют других данных, а сказки о смене базы также реальны как и про дюймовочку )
Тем не менее, общая логика есть, которой место в отдельном дата слое. В твоём же случае это будет дублирование кода со всеми вытекающими. И это не сказки, а реалии жизни.

маштабируемыйпрекрасно я тебя понял...
Умничка. Понимаешь ты не быстро, но таки понимаешь. Это намного лучше, чем какой-нибудь непробиваемый hVostt.
Итак, возвращаемся на исходную позицию про то, что я сам себе противоречу. Вопрос закрыт, как я понимаю?

маштабируемыйничего ты незнаешь не о РЕСТ, ни о коуч, ни о валидации, ни о модели...
Неубедительный и фееричный вброс, основанный на бесполезных эмоциях, когда тебя немножко втоптали в грязь. Это нормально, я не в обиде. Но мнение твоё мне фиолетово, всё же.

маштабируемыйты хватаешь в лапки горячие пирожки от .NET - и пытаешься впихнуть их под соусом, даже не заглядывая внутрь!!!
Я беру то, что мне нужно. И заглядываю туда, где мне необходимо.

ПарамонК примеру, прикручивал мобильную версию, к довольно не маленькому проекту, совсем другие интерфейсы, в половину меньше данных, осталась лишь маленькая часть логики которую можно было зашарить. Вынес ее в отдельную сборку - c'est tout )
А зачем вынес? Это же отдельная абстракция, не надо ничего выносить, сэкономил бы на количестве DLL.

ПарамонНикакого дублирования кода, и тесной связанности. Слой DTO фактически не пригодился.
Я выше тебе привел реальный привел с сайтом, рассылкой и полнотекстом. Что скажешь?

маштабируемыйв случае с коучбэйс - где ты валидируешь данные?
На стороне клиента и на стороне сервера приложений.

маштабируемыйпочему не в самой couchbase?
Такие вопросы даже студенты не задают, но тебе отвечу. Зачем напрягать БД, что за бред?

маштабируемыйТо есть ты честно признаёшь, что валидация данных - это забота клиента?
Я и всегда это признавал - только клиента. Причем, если применительно к вебу, то клиенту и серверу приложений. БД ничего валидировать не должна. Максимум, что там может сработать - это констреинты и проверки на null.

маштабируемыйв таком случае читай отсюда 14262977 и до забора - некий МСУ там пишет
автор Внимание вопрос, какая в задницу валидация аргументов на клиенте? :)
и тд
Ты похож на инопланетянина, который вообще не понял о чем речь и вырвал предложение из контекста. Для тех, кто в танке, поясняю: речь о WebAPI, который не умеет валидировать моель на клиенте - только на сервере приложений в апи контроллере. Это не значит, что эта клиентская валидация не нужна, её не сложно написать самостоятельно. Более того, в том же ASP.NET MVC есть unobtrusive validation на клиенте. После того, как прошла клиентская валидация, идет серверная валидация (ModelState.IsValid). И только после этого мы попадаем в БД. Что не ясно?

маштабируемый ПыСы БД для того и созданы, что бы их напрягать...
Учи матчать.

ПарамонПотому что была возможность повторного использования, в отличае от большинства DTO.
Что и требовалось доказать.

ПарамонМСУЯ выше тебе привел реальный привел с сайтом, рассылкой и полнотекстом. Что скажешь?

Рассылка и полнотекст нужны где либо еще? Если нет, могут жить в одном проекте.
Рассылка и полнотекст - это отдельные утилиты, которые сидят на вин шедулере и выполняют задачи по расписанию. Все компоненты солюшена используют общую сборку с датасервисом, этот датасервис в контроллерах прокидывается через слабосвязанный интерфейс IDataService. Я всегда могу изменить логику сервиса и достыковать к проектам. Приложения приобретают вид кубика рубика, который можно легко и безболезненно собирать по своему усмотрению. Такую архитектуру легко поддерживать и легко дорабатывать.

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

маштабируемыйты идиот? 14277918
По всей видимости не я, а ты. 14277918

маштабируемыйвсе твои напряги с couchbase понятны - она не предоставила тебе прямой возможности проверок и тебе приходится создавать отдельное приложение для этого!
Только так и никак иначе. Меня не интересуют возможности REST куча, это немасштабируемый вариант, у которого больше минусов, чем плюсов. Начиная от сложной логики в разрезе безопасности, роли, привилегии, группы и прочая канитель, которая гибко и элементарно решается на стороне сервера приложений. Никакого прямого доступа в БД, только через мой серверный слой (веб приложение, веб сервис, wcf сервис).

маштабируемыйдля клиентов твоего приложения моделью будет уже твоё приложение и им без разницы, что ты используешь в качестве хранилища...
Меня не интересуют дополнительные возможности и навороты куча, меня интересует только его скорость, присущая nosql базам.

маштабируемыйВ случае РБД - существует прекрасная возможность использовать ХП - почему бы ею не воспользоваться?
В случае РБД - существует прекрасная возможность использовать ORM. Использую его и только его. И всем рекомендую.
Теме сто лет в обед, баян. Читай местные холивары на эту тему и не ипи мне моск, студент.

маштабируемыйБД становится замкнутой сама в себе - она по сути превращается в модель - подконнектился и работаешь!!!
БД должна быть как можно тоньше, вся логика сосредоточена на сервере приложений.

маштабируемыйПро коуч ДБ вообще промолчу - она по сути модель, не нуждающаяся ни в чьей поддержке! 14278343
У куча несколько достоинств, каждый выбирает себе то, что нужно. Меня интересовала только скорость.

P.S. Опять возвращаемся к началу: итак, в чём я сам себе противоречил? Соберись!