Я считаю самый оптимальный вариант — чтобы все люди изучали два языка: свой родной и один общий («стандарт») — специально разработанный международной группой лингвистов. Этот язык должен быть заточен в первую очередь для делового общения, быть простым и достаточно мощным
Не пробовали использовать Watin? Если да, то не могли бы сказать о ± того и другого? Мне всегда казалось что Watin использовать удобнее из-за того, что там не требуется ничего кроме mstest
Нововведение с пейджингом — хорошо. Остальное лично я бы променял на select for update, который никак не сделают в sql server-e. И вообще уже давно пока привести систему блокировок в нормальный вид
Не нужно размывать ответственность между разными частями программы. Если вы работаете с документами по-другому (не так как с остальными объектами), то лучше и вьюхи сделать для нее свои, статические.
Универсализация хорошо работает для простых однотипных сущностей, если документы не вписываются в них, то лучше не пытаться их впихнуть туда «насильно» — постройте отдельную модель для работы с ними
2. Если данные из 100 таблиц отображаются в UI и не редактируются, не уходят обратно в базу, то можно считать их теми же отчетами — берем из БД данные, компонует, отображаем, о дальнейшем не волнуемся. Если же пользователь может менять их и сохранять, то доменная логика существенно усложняется и ее в общем случае лучше изолировать в соответствии с принципами DDD. Тут нужно принять решение как я описывал в п.1: если работа с этими таблицами не слишком сложна, доработка кода не занимает существенного кол-ва времени, то лучше оставить как есть — время затраченное на рефакторинг не окупится, иначе — нужно переписывать.
3. Если это обычный рид-онли sql-запрос — то ок, это не очень хорошо, но в целом нормально. Если же это нерид-онли запрос, то все плохо. Вы жертвуете читабельностью и простотой кода в пользу скорости работы программы и тем самым постепенно загоняете себя в ситуацию когда любые доработки модуля будут занимать неоправданно большое количество времени. Я рекомендую вам написать тесты, развязать модель, выделить доменную логику. Это может занять время, но за счет снижения сложности кода в дальнейшем снизится кол-во багов, уменьшится время, затрачиваемое на доработки. Если весь вопрос в скорости — выделите процесс пересчета скидок в отдельный ждоб (win-сервис), по максимуму используйте асинхронные операции
1. Реально. Тут как с рефакторингом — постепенно выделяете один модуль ИС за другим, изолируете доменную логику, переписываете. Если нет тестов — сначала пишете их (желательно крупнокалиберные, интеграционные, чтобы быть уверенным что рефакторинг такого масштаба не нарушил чего-либо). Но нужно быть готовым к существенным затратам времени — тут нужно сделать для себя выбор: иногда поддерживать не очень хорошо написанную систему проще чем переписывать (пусть по частям) ее «по-правильному». Если же в дальнейшем планируется ее серьезная доработка, дописывание функционала — то думаю да, это того стоит. Кстати для работы с legasy-системами в контексте DDD хорошо подходит NHibernate. Эта ORM позволяет очень гибко настраивать маппинг так, что можно будет построить правильную объектную модель не меняя (или почти не меняя) существующую структуру БД.
2. Такие задачи решаются в терминах DDD довольно просто. Для построения отчетов делаются специальные классы — DTO (Data transfer objects), по сути объектные аналоги датасетов. Эти DTO нужны только для компоновки и переноса данных наверх, в UI. Не вижу ничего плохого в использовании вместо DTO датасетов. Если данные, передаваемые в UI, в дальнейшем не меняются, то и беспокоиться о них не стоит — компонуете как нужно отчетам и забываете про них.
3. Было бы неплохо рассмотреть конкретные примеры. Как правило правильно построенная доменная модель + NHibernate решают все эти проблемы
Мне кажется хорошей такая схема патентного законодательства. Патенты выдаются сроком на 5 лет (к примеру), после этого все могут пользоваться технологией бесплатно. Этот срок (5 лет) поможет создать компании-патентодержателю задел для занятия нишы на рынке.
При этом технология может использоваться другими компаниями и до истечения срока если компания уплачивает фиксированный процент (к примеру 1%) за каждый патент с продажной цены каждого производимого устройства.
Такая схема будет стимулировать компании создавать новое, а не захапать патентов и сидеть на них бесконечно, а также как можно быстрее инвестировать в уже разработанные технологии
У меня показывает
Ну а дп — это просто мерзко, даже спамерам
Универсализация хорошо работает для простых однотипных сущностей, если документы не вписываются в них, то лучше не пытаться их впихнуть туда «насильно» — постройте отдельную модель для работы с ними
3. Если это обычный рид-онли sql-запрос — то ок, это не очень хорошо, но в целом нормально. Если же это нерид-онли запрос, то все плохо. Вы жертвуете читабельностью и простотой кода в пользу скорости работы программы и тем самым постепенно загоняете себя в ситуацию когда любые доработки модуля будут занимать неоправданно большое количество времени. Я рекомендую вам написать тесты, развязать модель, выделить доменную логику. Это может занять время, но за счет снижения сложности кода в дальнейшем снизится кол-во багов, уменьшится время, затрачиваемое на доработки. Если весь вопрос в скорости — выделите процесс пересчета скидок в отдельный ждоб (win-сервис), по максимуму используйте асинхронные операции
2. Такие задачи решаются в терминах DDD довольно просто. Для построения отчетов делаются специальные классы — DTO (Data transfer objects), по сути объектные аналоги датасетов. Эти DTO нужны только для компоновки и переноса данных наверх, в UI. Не вижу ничего плохого в использовании вместо DTO датасетов. Если данные, передаваемые в UI, в дальнейшем не меняются, то и беспокоиться о них не стоит — компонуете как нужно отчетам и забываете про них.
3. Было бы неплохо рассмотреть конкретные примеры. Как правило правильно построенная доменная модель + NHibernate решают все эти проблемы
При этом технология может использоваться другими компаниями и до истечения срока если компания уплачивает фиксированный процент (к примеру 1%) за каждый патент с продажной цены каждого производимого устройства.
Такая схема будет стимулировать компании создавать новое, а не захапать патентов и сидеть на них бесконечно, а также как можно быстрее инвестировать в уже разработанные технологии