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

bnk>>>Присоединяюсь к вопросу.
bnk>>>Что вы человека всякой абстракцией да литературой грузите
bnk>>>Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
bnk>>>Можно же наверное в двух словах показать, как это выглядит У ВАС?
bnk>>>

bnk>>>Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага
bnk>>>

MC>>Присоединяюсь. Очень интересно посмотреть как пишут люди с более высоким опытом.

K>А можно и я присоединюсь? 300 постов и НИ 1-го конкретного полного ответа на мои вопросы.
нормальные бюли ответы. Если вы ожидаете, что кто-то подготовит отрывки из проектов, упросчтит их, снадбит подробными разъяснениями то это наврятли... Вот например примерчег здесь. Куча всего интересного есть здесь, а вы всё ждёте пока вам всё разжуют...

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

kuj>Это в том числе и о тестировании синхронизации. В той мере, в которой ее вообще можно тестировать модульными тестами.
Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?

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

A>kuj думает, что T-SQL это императивный язык.
Вобщето таки императивный.

USE AdventureWorks;
GO
DECLARE @tablename sysname
SET @tablename = N'Person.AddressType'
table_loop:
   IF (@@FETCH_STATUS <> -2)
   BEGIN   
      SELECT @tablename = RTRIM(UPPER(@tablename)) 
      EXEC ('SELECT ''' + @tablename + ''' = COUNT(*) FROM '
            + @tablename )
      PRINT '  '
   END
   FETCH NEXT FROM tnames_cursor INTO @tablename
IF (@@FETCH_STATUS <> -1) GOTO table_loop
GO

(C)MSDN

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

kuj>>Это в том числе и о тестировании синхронизации. В той мере, в которой ее вообще можно тестировать модульными тестами.
WH>Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?

Никак не будет. Мсье — фантазёр. Ошибки синхронизации ловятся обёрткой примитивов синхронизации и распечаткой лога обращений к примитиву блокирующему поток. У Рихтера, кажется, есть такое для отладки CriticalSection. Но это самые сложные случаи, а вообще это отлаживается интуитивно Опыт решает.

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

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

A>>kuj думает, что T-SQL это императивный язык.
WH>Вобщето таки императивный.

Вообще-то смешанный. Какую часть ты будешь пользовать дело твоей совести. Я стараюсь императивную не использовать, потому что бизнес-логика на SQL это даже хуже, чем всё что обсуждали до этого.

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

A>Никак не будет. Мсье — фантазёр. Ошибки синхронизации ловятся обёрткой примитивов синхронизации и распечаткой лога обращений к примитиву блокирующему поток. У Рихтера, кажется, есть такое для отладки CriticalSection.
Логами можно только deadlock поймать.
A>Но это самые сложные случаи, а вообще это отлаживается интуитивно Опыт решает.
starvation и race condition только медитацией над кодом.
И если найти race condition довольно легко (настолько легко что их у меня не бывает) то ловить starvation реальный хардкор.

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

WH>И если найти race condition довольно легко (настолько легко что их у меня не бывает)

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

WH>то ловить starvation реальный хардкор.

starvation не deadlock, но очень похож. Если ловить слишком долго ждущие потоки, то из логов что-то можно вытянуть. Хотя нестабильность ситуации делает своё дело и мусора в логах выше крыши. Проще помедитировать.

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

A>starvation не deadlock, но очень похож.
Не ставь в один ряд deadlock и starvation.
deadlock штука примитивная. Их ловить очень легко. Их можно просто на бумажке нарисовать.
А вот starvation штука реально противная. Если мне кто раскажет как ловить starvation'ы буду очень благодарен.

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

WH>Не ставь в один ряд deadlock и starvation.
WH>deadlock штука примитивная. Их ловить очень легко. Их можно просто на бумажке нарисовать.
WH>А вот starvation штука реально противная. Если мне кто раскажет как ловить starvation'ы буду очень благодарен.

Я и не ставлю. В дедлоке поток ждёт навсегда, в старвайшене дольше чем полагается. Когда это дольше выражается 1-10 секундами простоя (пусть и иногда), отловить такие моменты можно (дедлоки тоже ловятся по принципу, кто ждёт больше 60 секунд, тот крайний). Если же у тебя 3мс вместо 1мс, то да, ты в жопе Только медитация.
Особенно забавно когда с голоданием борются увеличением потоков в пуле. Потом видим каменты к ревизии "500 потоков в пуле не хватало, сделал 1000".

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

A>>Но это самые сложные случаи, а вообще это отлаживается интуитивно Опыт решает.
WH>starvation и race condition только медитацией над кодом.
WH>И если найти race condition довольно легко (настолько легко что их у меня не бывает) то ловить starvation реальный хардкор.
Вообще говоря, starvation и lock contention можно было бы в большинстве случаев тоже достаточно легко находить, если была бы возможность инструментировать локи и смотреть на котором из них больше всего contender'ов висят.

В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.

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

C>Вообще говоря, starvation и lock contention можно было бы в большинстве случаев тоже достаточно легко находить, если была бы возможность инструментировать локи и смотреть на котором из них больше всего contender'ов висят.
C>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.

Хммм идея для меня новая, интересно. Правда боюсь опять будет информационный мусор в виде примитивов синхронизации, которых часто ожидают, но малый период времени (скажем ноль, Wait тут же возвратил управление).
В любом случае звучит первспективно. Захотелось добавить в .Net

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

[skip]
A>Таблицы с тех пор больше не перестраивались, наступило временное счастье.
A>Чуть позже выяснилось, что для инициализации объекта теперь требуется не один запрос к БД, а [количество полей + 1]. Это естестенно. На практике пришлось от автоматического мапинга отказатся, руками выгребать все User Properties для которых совпадал ID и раскидывать значения по полям класса руками. Так быстрее.
Эээ... ORM точно так же может:

public class UserProperties
{
   private final static String NAME_KEY="Name";
   private Map<String,String> storageMap;

   //Приватные, так как клиенты класса не должны напрямую трогать эту карту.
   private Map<String,String> getStorageMap() {return storageMap;}
   private void setStorageMap(Map<String,String> map) {return this.storageMap=map;}

   public void setFirstName(String name)
   {
       storageMap.set(UserProperties.NAME_KEY,name);
   }
   public void setFirstName()
   {
       return storageMap.get(UserProperties.NAME_KEY);
   }
   ...
}

//В мэппинге
...
<map name="storageMap" cascade="all-delete-orphan" lazy="false" fetch="join">
   <key column="id"/>
   <map-key column="name" type="string" length="32"/>
   <element column="value" type="string" length="128"/>
</map>
...

Выделенное — если нужна неленивая загрузка.

A>Конечно данную задачу можно решить и по-другому: кешированием. Кеширование объектов User снизило бы нагрузку на БД, только это не решение, а скрытие проблемы, работающее иногда. Если кешируемые объекты часто меняются (запрашиваются только для редактирования, например, SELECT и UPDATE будет поровну), кеш только ухудшит производительность. Проблему UPDATE это тоже не решает. Одно сохранение объекта выливается в [количество полей + 1] запросов в транзакции, вместо одного.
Для частоменяющихся объектов просто нужен хороший кэш. Ну и количество запросов будет вполне обычным, т.е. не отличающимся от ручного случая. Ну и всегда можно оптимизировать все — Hibernate позволяет использовать ХП для работы с коллекциями.

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

C> private final static String NAME_KEY="Name";
C> private Map<String,String> storageMap;

Это типа нормальное решение ты считаешь? Перенести работу DAL в Business Object. С какой стати класс User должен знать как он хранится в БД?

Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.

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

kuj>>Это в том числе и о тестировании синхронизации. В той мере, в которой ее вообще можно тестировать модульными тестами.
WH>Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?

Это не задача модульных тестов.

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

K>>А можно и я присоединюсь? 300 постов и НИ 1-го конкретного полного ответа на мои вопросы.

A>Нечего удивлятся. Кинуть какашкой в ближнего гораздо интереснее, чем отвечать на вопрос.

Очередная порция чуши:

A>Итак, у нас есть обработчик кнопки Это Presentation Layer. Не важно Model-View-Controller или Document-View у тебя всегда есть нечто, что надо дёрнуть: Model или Document. В первом случае обработчик кнопки это View, во втором — controller.

WinForms это не MVC, ни MVP, ни Document-View. Формы (визуальные контроллы) WinForms инкапсулируют функциональность и поведение и Controller`а и View в одном классе.

А Document-View это, например, MFC — с четким разделением на классы CView и CDocument.

A>Вообще говоря, и Model, и Document совсем не объязаны быть именно одним объектом.

Это ты только что придумал? Model-Document архитектура? Сильно...

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

C>> private final static String NAME_KEY="Name";
C>> private Map<String,String> storageMap;
A>Это типа нормальное решение ты считаешь? Перенести работу DAL в Business Object. С какой стати класс User должен знать как он хранится в БД?
Ну ладно, можешь сделать custom type — но там просто больше boilerplate-кода (кроме того, я не помню как его использовать, а в доку лень лезть).

А вообще — я бы не стал такой хак делать, а просто отдавал бы клиентам storageMap — нефиг скрывать такие детали доступа.

A>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
Так этот объект — это ЧАСТЬ DAL.

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

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

В вопросах обобщения действует чего-либо действует одно, но мощное правило:
1. Либо ты долго пишешь библиотеку, с помощью которой быстро решаешь определенный круг задач.
2. Либо ты берешь стандартный способ общения с БД, который прописан твоей средой разработки, и решаешь задачу стандартно.

У всего есть недостатки и преимущества.

Я использую первый вар-т. Но я свой MLObject (это наимощнейший предок на 30к строк) разрабатывал долго в частности в свое время — ну перло меня от этого. Он мощен неимоверно, но решает достаточно узкий круг задач бухучетной тематики.
Недостатком моего случая является тот факт, что носитель информации — автор, т.е. я. Есть какая-то обрывочная дока. Но на полноценную доку нет времени. Вот ушел сотрудник, который кроме меня знал мою библиотеку. Сейчас буду садиться за доку.

У второго вар-та тоже есть недостатки. Например, несистемность. Со временем подходы к использования станд. библиотеки разбредаются: здесь один подход, а в модуле, который писал другой программист, другой подход. Хотя проблемы несогласованности решаются административными методами.

Тебе же самому решать как быть: вар-т 1 или 2.

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

A>>>Кстати вот их то я совсем не догнал

kuj>>Если в кратце, то DDD подход упрощает тестирование за счет максимальной изоляции уровня домена от уровня data maping (DAL в простонародии).

kuj>>Для этих целей, например, используется паттерн Репозиторий (Repository), который выступает посредником между слоями. Такие репозитории можно размещать в отдельных сборках, что еще более упрощает unit-тестирование.

kuj>>Кроме того еще одним вариантом есть использование IoC-контейнеров (мы используем Spring и Castle Windsor).

kuj>>В итоге не имеем проблем с TDD подходом для кодирования на весьма большом проекте за исключением вполне естественных проблем на data maping уровне.

A>C репозитарием много непоняток. Писать кучу функций типа
A> IList<Order> GetOrdersByDateAndCustomer()
A>со всеми возможными комбинациями, которых может быть прилично+ новые подятся постоянно не очень хочеться.

А так примерно и получается. Зато BLL это именно BLL, который ничего о других слоях не знает и знать не хочет.

A>Постепенно приходим к осознанию необходимости Query object.

Ни в коем случае!

A>А писать самому query object неразумно, лучше уж тогда задействовать средства того же хибернета.

Hibernate нельзя...

A>Так что изоляцию от полная изоляция от сторонних средств и персистентного слоя нет.

Конечно больше приходится кодировать, зато окупается сполна. Например, у нас есть проектик (пока не большой, но перспективный), в котором три разных DAL, используемых в трех разных конфигурациях.

A>Плюс коллекции хибернета нарушают PI.

Не совсем понял. Разъясните пожалуйста.

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

Написал было ответ, но потом вспомнил что ты забанен и передумал. Да и о чём говорить с человеком, который фразу
Вообще говоря, и Model, и Document совсем не объязаны быть именно одним объектом.
не смог прочесть как
Вообще говоря, и Model в MVC, и Document в Document-View совсем не объязаны быть именно одним объектом.
что было очевидно, учитывая контекст.

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

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

C>А вообще — я бы не стал такой хак делать, а просто отдавал бы клиентам storageMap — нефиг скрывать такие детали доступа.

На то они и детали, чтоб скрывать.

A>>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
C>Так этот объект — это ЧАСТЬ DAL.

Я думал, что User в данном случае BO. BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.