вместо того, чтобы немного напрячь свой мозг и эрудицию, вы хотите поругаться. я ругаться не хочу и не буду, так как сильно занят.
но ладно, так уж и быть, сейчас я пью кофе и нагуглю все за вас. итак, распределенные архитектуры, краткий ликбез.
если приложение распределенное, это значит, что существуют отдельные процессы, которые в своей работе друг от друга зависят. если процессы разделены, то это скорее всего значит, что общение между ними происходит посредством сообщений. если один из процессов хочет быть транзакционным и случайно не нарушить целостность, то все, что ему нужно — это иметь транзакционный контроль над очередями сообщений. это к вашему пункту 1 замечание, что транзакции не только в данных бывают.
ну и все, куча архитектур подобным образом построена. бери любую, описывай, получай карму и плюсики.
Это все потому, что вы про такой мощный инструмент так просто пишете.
Really. Поботайте Microsoft Distributed Transactions service, разрюхайте распределенные архитектуры и распишите использование transaction scope уже в этом контексте.
Вряд ли интересно юзать System.Transactions в рамках одного процесса (гораздо проще IDbTransaction заюзать). В то же время спросите кого угодно про транзакции в сложных архитектурах, и послушайте ответы ;) Возможно, они сподвигнут вас написать еще одну статью, на этот раз с коментами и всеобщим почитанием;)
окей, уточняю. есть требования — написать слой работы с данными. на входе дто сущности, на выходе — инсерты и апдейты в бд. и наоборот — на входе вызовы методов слоя с параметрами, на выходе дто сущности.
Вопрос: как правильнее всего писать тесты в этом случае?
к аффтару: а вы чего такой поверхностный? хоть бы написали, чем cross apply от outer apply отличается.
еще могу порекомендовать прочитать книжку:
www.amazon.com/Microsoft%C2%AE-Server%C2%AE-T-SQL-Fundamentals-PRO-Developer/dp/0735626014
в интернете полно где лежит.
где финальный график с 4:24 до «меньше чем за минуту»? Ж)
а обзор провайдеров моков, стабов, упрощение жизни программиста? риномоки, моq, moles? или как, писать все эти шпиёны-заглушки ручками?
афтар похож на графомана больше, чем на умудренного гения.
еще небось жена и дети есть?:)
но ладно, так уж и быть, сейчас я пью кофе и нагуглю все за вас. итак, распределенные архитектуры, краткий ликбез.
если приложение распределенное, это значит, что существуют отдельные процессы, которые в своей работе друг от друга зависят. если процессы разделены, то это скорее всего значит, что общение между ними происходит посредством сообщений. если один из процессов хочет быть транзакционным и случайно не нарушить целостность, то все, что ему нужно — это иметь транзакционный контроль над очередями сообщений. это к вашему пункту 1 замечание, что транзакции не только в данных бывают.
ну и все, куча архитектур подобным образом построена. бери любую, описывай, получай карму и плюсики.
2) профайлер вам в помощь;)
3) хз. имхо хрень
про дискуссию — ну вот написали вы статью, получили свои плюсики. с тем же успехом можно было дать ссылку на мсдн.
про распределенные архитектуры — ботайте MSDTC, MSMQ, книжки по архитектуре.
Это все потому, что вы про такой мощный инструмент так просто пишете.
Really. Поботайте Microsoft Distributed Transactions service, разрюхайте распределенные архитектуры и распишите использование transaction scope уже в этом контексте.
Вряд ли интересно юзать System.Transactions в рамках одного процесса (гораздо проще IDbTransaction заюзать). В то же время спросите кого угодно про транзакции в сложных архитектурах, и послушайте ответы ;) Возможно, они сподвигнут вас написать еще одну статью, на этот раз с коментами и всеобщим почитанием;)
Вопрос: как правильнее всего писать тесты в этом случае?
подскажите, а как правильно писать юниттесты для такого рода компонент, как Data Abstract Layer?