Здравствуйте, <Аноним>, Вы писали:
А>Это все классно, но какова структура класса Filter?
Зависит от того, что ты хочешь фильтровать.
А>По идее фильтр — набор выражений сравнения (=, <>, between and, in, >, <, is null, и т.д.), соединенных между собой булевыми операторами (and, or). Ну и там всякие еще not добавляются....
Это если ты пишешь платформу и нужен универсальный фильтр на все вермена.
А если ты решаешь конкретную задачу, то и так ясно, что начальную дату всегда надо сравнивать на больше, конечную на меньше, идентификатор на равенство и т. д. Иными словами, фильтр представляет собой голый набор строго типизированых данных, а AppServer сам знает что с ними делать.
Если же у тебя задача универсальный фреймворк написать, то да без серивализации Expression Tree не обойтись, но для подавляющего большинства практических задач — это явный перебор.
Здравствуйте, IB, Вы писали:
IB>Зачем так сложно? С клиента на сервер достаточно передать простой объект типа Filter, а уж подставить его данные в линковский запрос на сервере — не бином ньютона. IB>Нет никакой разницы, прямо на клиенте из данных контрола генерить запрос или передать эти данные на сервер и строить на основе этих данных запрос там, просто для второго случая не нужно свой IQueryable изобретать и учиться его сериализовать. Что вас всех так тянет свой LINQ-провайдер на ровном месте писать?
Просто как показывает опыт, все системы передачи фильтрации на сервер рано или поздно превращаются либо в нечто жуткое и неподдерживаемое (dateDocFrom, DateDocTo, dateDocAndXFrom, DateDocAndXTo, etc.), либо в некое подобие LINQ-провайдера (точнее, его транспортной части), оставаясь при этом сильно заточенным под конкретный проект а потому плохореюзабельным. Свой LINQ-провайдер же представляет из себя универсальную систему (ибо принципиально не завязан ни на какую контекстнозависимую информацию), а потому его легко реюзать...
Здравствуйте, koandrew, Вы писали:
K>Просто как показывает опыт, все системы передачи фильтрации на сервер рано или поздно превращаются либо в нечто жуткое и неподдерживаемое (dateDocFrom, DateDocTo, dateDocAndXFrom, DateDocAndXTo, etc.),
Ну не знаю, мой опыт ничего подобного не показывает.
K>Свой LINQ-провайдер же представляет из себя универсальную систему (ибо принципиально не завязан ни на какую контекстнозависимую информацию), а потому его легко реюзать...
Угу, только пока сделаешь, забудешь зачем он нужен.
Здравствуйте, koandrew, Вы писали:
K>Свой LINQ-провайдер же представляет из себя универсальную систему (ибо принципиально не завязан ни на какую контекстнозависимую информацию), а потому его легко реюзать...
Никто не спорит, что свой провайдер — это хорошо. Особенно хорошо, если он уже есть из коробки и его делать не надо. С ним становятся доступны инструменты быстрой разработки типа dynamic data (при словах быстрая разработка у архитекторов(тм) начинает глаз дергаться ) , его гораздо легче использовать, и практически все модификации остаются на клиенте. Но есть и проблема — очень большая трудоемкость и сложность реализации.
В общем, как у классика. Выбирай — но осторожно. Осторожно — но выбирай (с)
Здравствуйте, Gollum, Вы писали:
G>Никто не спорит, что свой провайдер — это хорошо. Особенно хорошо, если он уже есть из коробки и его делать не надо. С ним становятся доступны инструменты быстрой разработки типа dynamic data (при словах быстрая разработка у архитекторов(тм) начинает глаз дергаться ) , его гораздо легче использовать, и практически все модификации остаются на клиенте. Но есть и проблема — очень большая трудоемкость и сложность реализации. G>В общем, как у классика. Выбирай — но осторожно. Осторожно — но выбирай (с)
Дык а я и не говорил, что это просто. Что я говорил — это инвестиции в будущее, ибо написав однажды, можно будет с минимальными переделками (а то и вообще без оных) использовать и в других проектах...
Здравствуйте, koandrew, Вы писали:
K>Дык а я и не говорил, что это просто. Что я говорил — это инвестиции в будущее, ибо написав однажды, можно будет с минимальными переделками (а то и вообще без оных) использовать и в других проектах...
Есть опасность, что пока вы будете писать провайдер, конкуренты сделают продукт Впрочем, если ресурсы и деньги есть, то почему нет...
Здравствуйте, Аноним, Вы писали:
А>По-моему махровым велосипедом попахивает... LINQ, мне кажется, не совсем то, что нужно: хочется иметь один класс контроллера фильтров для всех классов бизнес-сущностей...
Я готового под WinForms не встречал. Под АСП.НЕТ есть, под Силверлайт тож есть.
В любом врядли имеет смысл делать что-то супер генерик. По опыту, все заканчиваеться до десятка типов фильтров. Пишется не напряжно.
Здравствуйте, Аноним, Вы писали:
А>Доброго времени суток! А>Вопрос такой: как по вашему мнению правильнее всего организовать фильтрацию строк в формах, где отображаются списки бизнес-сущностей, загружаемых из базы данных в приложении на .NET. Например, есть диалог "Заказы". В нем есть Grid со списком заказов. В том же диалоге есть кнопка "фильтр", по нажатию на которую открывается диалог настройки фильтра (где можно задать номер или часть номера, дату заказа или интервал дат, заказчика или список заказчиков, общую сумму заказ или интервал сумм). Поскольку заказов может быть ОЧЕНЬ много и затягивать из СУБД их все слишком расточительно, то применение фильтра должно в конечном счете приводить к модификации текста запроса, уходящего в СУБД. А>Интересует вариант с 3-хзвенной архитектурой, когда условие фильтрации (дерево выражений?) надо передавать с клиента на сервер приложений в форме отличной от SQL-запроса. А>Я пока вижу часть решения так (для случая с "Заказами"): А>1. Есть класс "Заказы", обвешанный атрибутами (пока не знаю какими именно), хранящими метаинформацию о бизнес-сущности "Заказ". А>2. Некий контроллер фильтра при инициализации получает переменную типа Type: А>
А>FilterController fc = new FilterController(typeof(ЗАКАЗЫ))
А>
А>и на основе информации, содержащейся в атрибутах класса ЗАКАЗЫ настраивает FilterControl (наследник UserControl'а). А>3. Пользователь, работая с FilterControl'ом, настраивает условия фильтрации в контроллере фильтра. А>4. На выходе контроллер фильтра должен преобразовать полученное условие фильтрации в виде некоторого дерева выражений, пригодного для сериализации (его же надо передать посредствам WCF на сервер приложений) и интерпретации в SQL-код в слое DAL.
А>По-моему махровым велосипедом попахивает... LINQ, мне кажется, не совсем то, что нужно: хочется иметь один класс контроллера фильтров для всех классов бизнес-сущностей...
А модель выражения, будь то expression tree или любая другая хрень, преобразовать в where-кляузу — халявная задача. Я не понял про какие Linq-провайдеры и человеконедели тут речь была. Самая трудоемкая хрень в этом всем — UI.
Здравствуйте, <Аноним>, Вы писали:
А>Доброго времени суток! А>Вопрос такой: как по вашему мнению правильнее всего организовать фильтрацию строк в формах, где отображаются списки бизнес-сущностей, загружаемых из базы данных в приложении на .NET. Например, есть диалог "Заказы". В нем есть Grid со списком заказов. В том же диалоге есть кнопка "фильтр", по нажатию на которую открывается диалог настройки фильтра (где можно задать номер или часть номера, дату заказа или интервал дат, заказчика или список заказчиков, общую сумму заказ или интервал сумм).
Для решения подобных задач я написал парсер/транслятор поисковых запросов. Весь UI для пользователя — строка ввода запроса a la Google. Пользователь вводит "дата:01.11.2009..10.11.2009 заказчик:Петров -заказчик:Иванов сумма:>1000руб", транслятор генерирует expression tree — которое либо компилируется в предикат для фильтрации UI, либо встраивается в запрос LINQ. Для сериализации используется исходный запрос пользователя.
Мы уже победили, просто это еще не так заметно...
