1) реально
2) много
3) лучше не заморачиваться

OracleLoverвся бизнес-логика должна быть реализована в БД
Ни в коем случае. Масштабировать логику в тысячи раз проще и правильнее на app layer. Баян ведь.

маштабируемый, начни понимать отсюда:
http://msdn.microsoft.com/en-us/library/ff649690.aspx
http://msdn.microsoft.com/en-us/magazine/dd569757.aspx

OracleLoverперетерли стопиццот раз уже, я ЗА ормки, хотел просто сказать что есть люди которые либо привыкли, либо просто считают что так надежнее хранить бизнес логику в базе. Их право.
Согласен, пусть эти староверы утешают себя фантастическими сказками про производительность и безопасность. Но, как правило, задница у них наступает тогда, когда появляется сложная логика доступа к данным в разрезе ролей и привилегий. На стороне app layer такие вещи пишутся просто и поддерживаемо. Знавал я такие ПО на сиквельных ролях и учетках, просто мрак.

маштабируемый 14278959 - и что ты мне запилил? 14278898 - читай вопрос!!!
Читай ответ, в ссылках есть ответ на баян, который ты вбросил. Если не осилишь, шагом марш в сад.

маштабируемый 14278356 14279050 - ты сам себе противоречишь!!!
либо ты не работал с CouchDB, либо ты использовал её на 5% от её возможностей!!!
В чем именно ты увидел противоречие?

маштабируемыйВалидация на клиенте!?
?

маштабируемыйты утверждал что работал с CouchDB! как ты её использовал?
Так вот сначала узнай, как я ее использовал, а потом говори, что я себе противоречу. Ок?

маштабируемыйнакинул ОРМ в своё приложение и только сохранял доставал данные из\в коуч, а всю работу оставил ОРМ?
Я десятый раз повторяю, ты читал мои ссылки на тему шаблонов проекитрования, а именно репозиторий?

маштабируемыйили использовал внутренние механизмы коуча?
validate_doc_update
views
updates
Враппер , натянутый на свой IRepository. Все телодвижения через объектную модель .NET.

маштабируемыйПодумай!
Пойми!

Парамон, ну знаешь ли - код трудно понять разработчиков, которые не знакомы с шаблоном, это не аргумент. Пусть знакомятся с шаблоном, тогда будет и понимание. Во-вторых, реализация шаблона уменьшает количество избыточного код - это, ведь, достоинство. В-третьих, откуда там рост времени разработки, для меня загадка. Как-раз наоборот.

P.S. Для общего мировоззрения: я по сути приравниваю между собой шаблоны репозитория и датасервиса в контексте БД. Второе определение для меня более корректнее.

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

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

маштабируемыйавторТак вот сначала узнай, как я ее использовал, а потом говори, что я себе противоречу. Ок?
http://couchdb.apache.org/ vs http://www.couchbase.com/

ничего не смущает!?

полагаю разговор на этом можно закончить...

couchbase - это продолжение развития усопшего couchdb, иди буквари лучше читай, робинзон открыватель

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

ПарамонЕсли ты про автогенерацию дата модели в 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. Опять возвращаемся к началу: итак, в чём я сам себе противоречил? Соберись!

маштабируемый1 - краткость сестра таланта - твои простыни говорят сами за себя...
Да имеющий моск поймет. Но это, видимо, не про тебя...

маштабируемый2 - "БД должна быть как можно тоньше, вся логика сосредоточена на сервере приложений." - это твоё мнение, которое в данном случае меня меньше всего беспокоит!!!
Открой для себя application architecture guide: http://codearticles.ru/articles/1522 почитай перед сном, может, поумнеешь немного.

маштабируемый3 - "Опять возвращаемся к началу: итак, в чём я сам себе противоречил?" - ну читай по тексту - где же по мнению МСУ должна быть валидация? ;))) 14277918 на сервере или 14279741 на клиенте? ;)))
Унылый соскок с ответа на прямой вопрос. Я тебе уже 10 раз сказал, где должна быть валидация, но ты упорно продолжаешь сидеть в танке. Сиди.

маштабируемыйавторУнылый соскок с ответа на прямой вопрос.
ну так какой ответ ты выбираешь?
а - 14277918
б - 14279741

Танкисты начинают маневрировать между деревьями?

маштабируемыйавторпочитай перед сном,
я такие вещи не читаю - особенно перед сном (и др не советую) - страшно!!!
Правильно, тупым страшно - умным занятно. Не бойся знаний.