Я уже некоторое время использую WWF как часть внутреннего приложения центра обработки вызовов (ASP.NET), и хотя это была хорошая практика в понимании того, как должна работать система документооборота на основе государственных машин, я определенно не влюблен в WWF сам по себе. На мой взгляд так оно и есть:

1. Чрезмерно сложный, особенно для использования в веб-приложениях (все эти потоковые вещи во время выполнения)
2. Незрелый (когда-нибудь работал с этим ужасным дизайнером?)
3. Анемичный в своем текущем наборе функций

Есть ли у кого-нибудь предложения по улучшению структуры рабочего процесса на основе .NET? В частности, я ищу следующие функции:

1. Состояние на основе машины (сопоставление состояний с доступными действиями)
2. Фокус на разрешениях пользователей (управление тем, кто имеет доступ к каким действиям)
3. Возможность запуска рабочих процессов в качестве временных фоновых задач (например, для отправки напоминаний для элементов, которые находились в определенном состоянии в течение x дней)

Это действительно все, что мне нужно. Мне не нужно быть в состоянии "drag and drop" какие-либо действия или визуально проектировать поток. Я совершенно комфортно пишу фактический код, как только запускается определенное действие.

Кто-нибудь сталкивался с этой проблемой во время установки приложения?

• OS - это Windows сервер 2k3

У меня есть доступ к локальному администратору, и я установил это приложение на других машинах. Любая помощь будет очень признательна, так как Google не очень помогает

Таким образом, платформа ADO.NET Entity Framework получила немного плохую прессу (в виде записей в блоге и петиции), но я не хочу спешить с суждением. Я ограничен во времени для экспериментов, но мне было интересно, работал ли кто-нибудь с ним еще с большей эмпирической обратной связью?

Наконец, каковы мысли об использовании NHibernate, который существует уже давно и может быть более зрелым, чем ADO.NET Entity Framework.

При написании запросов к базе данных в чем-то вроде TSQL или PLSQL у нас часто есть выбор: перебирать строки курсором для выполнения задачи или создавать один оператор SQL, который выполняет одну и ту же работу одновременно.

Кроме того, у нас есть возможность просто вытащить большой набор данных обратно в наше приложение и затем обработать его строка за строкой, с помощью C#, Java, PHP или чего-то еще.

Почему лучше использовать запросы на основе наборов? Какая теория стоит за этим выбором? Каков хороший пример решения на основе курсора и его реляционного эквивалента?

Я нахожусь в процессе рефакторинга некоторого кода, который включает перемещение папок вокруг, и я хотел бы регулярно merge, чтобы держать вещи в курсе. Что является лучшим способом, чтобы merge после того, как я переместил папки в моей рабочей копии?

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

Я разработал генератор кода, который принимает наш интерфейс python к нашему коду C++ (сгенерированному через SWIG) и генерирует код, необходимый для того, чтобы представить его как WebServices. Когда я разрабатывал этот код, я делал это с помощью TDD, но мои тесты оказались чертовски хрупкими. Поскольку каждый тест по существу хотел проверить, что для заданного бита входного кода (который оказывается заголовком C++) я получу заданный бит выходного кода, я написал небольшой движок, который читает определения тестов из входных файлов XML и генерирует тестовые случаи из этих ожиданий.

Проблема в том, что я вообще боюсь идти на изменение кода. Это и тот факт, что сами юнит-тесты а: сложны, а б: хрупки.

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

Есть ли у кого-нибудь опыт чего-то подобного, которым они хотели бы поделиться?