LINQ to SQL, Entity Framework в ASP.NET
Вроде же микрософт вей в asp.net это дата сорсы?
Вопрос: можно ли их как-нибудь с малыми затратами труда подружить какой-нить ORM и ASP.NET?использовать ORM в легком режиме (в режиме чтения и без ленивых запросов при update заново вычитывать элементы
псевдокод
// генерация страницы
page.Controls.AddRange(linqReadonlyContext.Items.Select(item => new Label{Text=item.name};
// изменение данных
var item = linqUpdateableContext.Items.First(_item => _item.Id == changedItemId);
item.Value = newValue;
linqUpdateableContext.SubmitChanges;
Вроде же микрософт вей в asp.net это дата сорсы?текущей way: dynamic data
http://www.asp.net/dynamicdata/
при update заново вычитывать элементыгыы лол
, видно ты не программировал хоть сколько-нибудь сложную ASP.NET форму. То, что ты описал, не работает когда на форме редактируется сущность и связанные с ней коллекции.как подружить ORM'ы с ASP.NETНа самом деле проблема действительно ЕСТЬ! А Майкрософт ее в упор не видит.
У нас самописный ORM, и контекст там может сериализоваться. Мы его сериализуем не во вьюстейт, а в BLOB в базу.
гыы лол , видно ты не программировал хоть сколько-нибудь сложную ASP.NET форму. То, что ты описал, не работает когда на форме редактируется сущность и связанные с ней коллекции.Да, такое будет.
В случае с DataSet'ами и DataAdapter'ами всё просто. Есть отключенный DataSet, сериализованный во ViewState страницы.Это ты где такие "простые" рекомендации прочел?
Это ты где такие "простые" рекомендации прочел?А что не так с ними?
гыы лол , видно ты не программировал хоть сколько-нибудь сложную ASP.NET форму. То, что ты описал, не работает когда на форме редактируется сущность и связанные с ней коллекции.и в чем будет проблема?
у нас так даже толстый клиент успешно бегает.
гыы лол , видно ты не программировал хоть сколько-нибудь сложную ASP.NET форму. То, что ты описал, не работает когда на форме редактируется сущность и связанные с ней коллекции.кстати в этой фразе лишь эмоции, и нет ни кусочка информации(довода/утверждения/примера и т.д. которые бы показывали что я ошибаюсь.
У нас самописный ORM, и контекст там может сериализоваться.зачем это надо? что вы нового(то, что нельзя заново прочитать из базы) храните в контексте?
кстати в этой фразе лишь эмоции, и нет ни кусочка информации(довода/утверждения/примера и т.д. которые бы показывали что я ошибаюсь.Потому что проблема достаточно тонкая, и описать ее полно с примерами в одном сообщении я не собирался. Но с коллекциями это, действительно, не работает.
Если есть желание обсудить эту проблему, тогда начнем. Пусть у нас на одной форме редактируется все четыре сущности вот из этого примера. Элементы в коллекциях QuoteJob, QuotePart, QuoteOtherExpense могут добавляться и удаляться. При работе пользователя с формой между браузером и сервером происходит несколько раундтрипов, а в конце пользователь либо нажимает кнопку Save, либо Cancel, либо ничего не нажимает и просто закрывает браузер. Естественно, что изменения должны быть зафиксированы в системе, только если нажата кнопка Save.
Опиши, как вы обрабатываете эту ситуацию без промежуточного хранения дата-объектов? Вы храните состояние объекта добавлен/удален/обычный на форме? Значения FK вы тоже храните на форме? Какие-нибудь скрытые поля, не присутствующие явно на форме, вы тоже храните на форме? И при каждом реквесте вы это все восстанавливаете в контексте ORM-а? Фактически это дублирование обязанностей, возложенных на ORM. Да, так это будет работать, но, как отметил топикстартер, это слишком много работы для программиста. Может быть, и можно выделить это все в инфраструктуру, но я не думал в этом направлении – не было настолько свободно поставленной задачи. Эта инфраструктура будет как-то необычно перемешивать уровни презентейшен и бизнес логики, и поэтому народ будет с усмешкой на это смотреть.
При работе пользователя с формой между браузером и сервером происходит несколько раундтрипов, а в конце пользователь либо нажимает кнопку Save, либо Cancel, либо ничего не нажимает и просто закрывает браузер. Естественно, что изменения должны быть зафиксированы в системе, только если нажата кнопка Save.во-первых: почему все это хранится на сервере? а не в браузере?
во-вторых: почему эти изменения считаются "временными" и сразу(по мере ввода) не сохраняются(интегрируются) в систему? а ожидается команда save?
во-первых: почему все это хранится на сервере? а не в браузере?я ж уже написал об этом
во-вторых: почему эти изменения считаются "временными" и сразу не сохраняются(интегрируются) в систему по мере ввода? а ожидается команда save?
Потому что для пользователя это все один документ Quote, то что в системе они представлены 4-я сущностями его не волнует.
и сразу(по мере ввода)а ты хотел бы чтобы все твои ошибки/описки интегрировались в систему?
Потому что для пользователя это все один документ Quote, то что в системе они представлены 4-я сущностями его не волнует.почему вы не разрешаете пользователю сохранять частично заполненные quote?
почему вы не разрешаете пользователю сохранять частично заполненные quote?где ты такое прочитал? Он всегда может нажать кнопку Save.
а ты хотел бы чтобы все твои ошибки/описки интегрировались в систему?т.е. вы не интегрируете изменения ради того, чтобы пользователю предоставить наглядный способ видеть свои ошибки?
где ты такое прочитал? Он всегда может нажать кнопку Save.т.е. если пользователь нажмет save только на части действия которое он хотел сделать, то проблем не будет?
т.е. вы не интегрируете изменения ради того, чтобы пользователю предоставить наглядный способ видеть свои ошибки?Не только! Это я тебе написал, в надежде, что это заставит тебя подумать в направлении, что описанная мной схема является естественной/ожидаемой для пользователя. При работе с документами на компьютере это обычная практика, а потому ожидаема пользователем.
во-вторых: почему эти изменения считаются "временными" и сразу(по мере ввода) не сохраняются(интегрируются) в систему? а ожидается команда save?А вы не считаете такие изменения "временными" и сразу фиксируете в системе?
т.е. если пользователь нажмет save только на части действия которое он хотел сделать, то проблем не будет?проблемы не будет только, если при каждом реквесте на сервер будет нажиматься кнопка Save. Т.е., скажем, провести валидацию и расчеты с помощью бизнес-объектов не удастся. Ну то есть какой-то бред.
, что описанная мной схема является естественной/ожидаемой для пользователя.т.е. ты считаешь, что модель офиса более естественная, чем модель гугл докс?
т.е. ты считаешь, что модель когда надо два раза вносить исправления: один раз как временные (непосредственный ввод а второй раз как постоянные (кнопка save) более естественная?
т.е. ты считаешь, что модель офиса более естественная, чем модель гугл докс?с гугл докс не работал. Работаю с gmail, там система аналогичная офису.
два раза вносить исправленияче за бред?
вообще, может быть ты так неуклюже намекаешь на один из трех способов сохранения состояния, описанных у Фаулера — сохранение состояние в базу. Тогда можешь у Фаулера и про недостатки этого способа почитать.
все что ты говоришь: разделение на бизнес логику и отображение, кнопка save, фаулер и т.д. - это ты все говоришь о потребностях разработчиков.
пользователю все это не надо, пользователь лишь хочет внести изменение.
возможны следующие сценарии действия пользователя:
1. пользователь на время делает ветку, в эту ветку вносит изменения, смотрит как изменение повлияло на мир, корректирует изменение по необходимости, по результату - ветку интегрирует в общий мир, или отменяет.
2. пользователь вносит изменение в мир, смотрит как оно повлияло на мир; отменяет изменение, если оно не понравилось.
все интерфейсы строятся как комбинация двух этих сценариев.
и соответственно, в первом сценарии - есть кнопка "применить мои изменения к миру", а не save
а во втором случае - кнопки save вообще нет.
например, графический редактор:
делаем ветку в память (оставляя основной мир на диске
далее все действия применяем сразу на локальный мир с возможностью отката,
интегрируем полученное изменение с версией на диске (интеграция простая - в виде перезаписи всего).
пользователю все это не надо, пользователь лишь хочет внести изменение.
возможны следующие сценарии действия пользователя:
1. пользователь на время делает ветку, в эту ветку вносит изменения, смотрит как изменение повлияло на мир, корректирует изменение по необходимости, по результату - ветку интегрирует в общий мир, или отменяет.
2. пользователь вносит изменение в мир, смотрит как оно повлияло на мир; отменяет изменение, если оно не понравилось.
все интерфейсы строятся как комбинация двух этих сценариев.
и соответственно, в первом сценарии - есть кнопка "применить мои изменения к миру", а не save
а во втором случае - кнопки save вообще нет.
например, графический редактор:
делаем ветку в память (оставляя основной мир на диске
далее все действия применяем сразу на локальный мир с возможностью отката,
интегрируем полученное изменение с версией на диске (интеграция простая - в виде перезаписи всего).
минусы/ограничения первого сценария(branch/change/merge): делать ветку в мультиагентной среде можно лишь на короткое время, т.к. на чем большее время мы делаем ветку, тем больше изменений накапливается в "мире", тем сложнее делать окончательную интеграцию нашей ветки с "миром".
минусы/ограничения второго сценария(change/undo): есть действия, которое невозможно или дорого отменять.
минусы/ограничения второго сценария(change/undo): есть действия, которое невозможно или дорого отменять.
А вы не считаете такие изменения "временными" и сразу фиксируете в системе?по твоим наводящим вопросам я понял следующее:
1. само изменение транзакционное, т.е. его не стоит дробить на части
2. откат изменения в вашей системе дорог или невозможен
2. ветку ты считаешь делать правильно на уровне состояния сессии, но не на уровне всего мира (т.е. мир не знает о том, что кто-то где-то делает ветку и не на уровне клиента (в браузере)
я правильно сформулировал?
все что ты говоришь: разделение на бизнес логику и отображение, кнопка save, фаулер и т.д. - это ты все говоришь о потребностях разработчиков.Ты читал Фаулера то? У него на протяжении всей книги используется термин "бизнес-транзакциями". И у него есть рассуждения те, о которых ты тут пытаешься писать.
Вот введение в главу "Сеансы и состояния"
Глава 6
Сеансы и состояния
Различия между системными и бизнес-транзакциями уже рассматривались при обсу-
ждении параллельного выполнения заданий (см. главу 5). Эти различия не только влияют
на те или иные аспекты параллелизма, но и обусловливают способы сохранения в кон-
тексте транзакции информации временного характера, которая до определенного момен-
та не может фиксироваться в базе данных.
Те же принципиальные различия лежат в основе многих дискуссий о роли и месте так
называемых сеансов с сохранением промежуточного состояния (или, коротко говоря, сеан-
сов "с состоянием") (stateful sessions) и сеансов "без состояния" (stateless sessions). По этому
поводу сломано немало копий, но, как мне кажется, основная проблема нередко оказы-
вается скрытой за частоколом сугубо технических вопросов. Необходимо понимать, что
"состояние" является неотъемлемой частью сеансов определенных категорий и даль-
нейшие решения должны приниматься только с учетом этого факта.
Тут явно говориться о временных данных.
2. пользователь вносит изменение в мир, смотрит как оно повлияло на мир; отменяет изменение, если оно не понравилось.
Если вам удалось убедить ваших пользователей в этом варианте, то вашим пользователям можно только посочувствовать
и я правильно понял, что у вас пользователь не может инициировать одновременно два изменения?
т.е. грубо говоря не может открыть два окна браузера, и в обоих окнах что-то одновременно менять?
т.е. грубо говоря не может открыть два окна браузера, и в обоих окнах что-то одновременно менять?
Ты читал Фаулера то?еще раз повторю, что фаулер пишет о другом, он пишет о технической реализации.
оно никакого отношения к тому что я написал не имеет.
пишет о технической реализациикороче ты не читал
короче ты не читалты похоже не читаешь то, что тебе пишут.
у фаулера вводятся понятия реализации:
сохранение состояния на стороне клиента
сохранения состояния на стороне сервера
сохранения состояния на стороне базы данных
это совсем не тоже самое, что понятия логики:
ветка делается на уровне формы,
ветка делается на уровне сессии,
ветка делается на уровне мира.
ветка может делаться на уровне формы, но хранится при этом в базе данных,
и наоборот ветка делается на уровне мира, но хранится на форме.
сохранение состояния на стороне клиента
сохранения состояния на стороне сервера
сохранения состояния на стороне базы данных
это совсем не тоже самое, что понятия логики:
ветка делается на уровне формы,
ветка делается на уровне сессии,
ветка делается на уровне мира.
ветка может делаться на уровне формы, но хранится при этом в базе данных,
и наоборот ветка делается на уровне мира, но хранится на форме.
и я правильно понял, что у вас пользователь не может инициировать одновременно два изменения?В одном документе?
т.е. грубо говоря не может открыть два окна браузера, и в обоих окнах что-то одновременно менять?
В одном документе?интересует оба варианта: в одном документе, в разных документах.
то совсем не тоже самое, что понятия логики:Еще раз, у Фаулера есть понятие "бизнес-транзакция" без относительно к реализации. Твои ветки вроде напоминают фаулеровские бизнес-транзакции. Я предпочитаю пользоваться фауревской терминологией. У транзакции всегда есть команда Commit.
еще раз повторю, что фаулер пишет о другом, он пишет о технической реализации.третий раз скажу, Фаулер пишет не только о техническом аспекте. Он как раз явно говорит, что это бизнес требования к системе и их надо обсуждать с людьми, которые разбираются в бизнесе, который мы автоматизируем.
оно никакого отношения к тому что я написал не имеет.
интересует оба варианта: в одном документе, в разных документах.нашим заказчикам было достаточно, чтобы два окна браузера рассматривались как два пользователя.
Еще раз, у Фаулера есть понятие "бизнес-транзакция" без относительно к реализации. Твои ветки вроде напоминают фаулеровские бизнес-транзакции. Я предпочитаю пользоваться фауревской терминологией. У транзакции всегда есть команда Commit.я плохо понимаю что такое бизнес-транзакция для случая:
начинаю вносить изменение, но приходится прерваться, поэтому изменение сохраняется как черновик.
это бизнес-транзакция? или нет?
я плохо понимаю что такое бизнес-транзакция для случая:да
начинаю вносить изменение, но приходится прерваться, поэтому изменение сохраняется как черновик.
это бизнес-транзакция? или нет?
Давай все-таки ближе к теме треда. Давай остановимся на первом твоем сценарии. Второй я считаю бредом.
Как ты этот сценарий реализуется той схемой, которую ты написал вначале треда? Через фаулеровское "Сохранение состояния в базе"?
1. пользователь на время делает ветку, в эту ветку вносит изменения, смотрит как изменение повлияло на мир, корректирует изменение по необходимости, по результату - ветку интегрирует в общий мир, или отменяет.
Как ты этот сценарий реализуется той схемой, которую ты написал вначале треда? Через фаулеровское "Сохранение состояния в базе"?
нашим заказчикам было достаточно, чтобы два окна браузера рассматривались как два пользователя.из этого не следует однозначный ответ на мой вопрос...
т.е. до сих пор непонятно, что будет если:
1. нажать undo
2. открыть тоже самое, но еще одной вкладкой (с тем же только url-ом, или с тем же состоянием страницы)
3. выполнить ту же самую последовательность нажатий кнопок, что и при открытии первой страницы
дано в том, что я писал - это не есть бизнес-транзакция, это есть незаконченная ветка.
поэтому еще раз повторю, что фаулер описывает реализацию
т.е. до сих пор непонятно, что будет если:короче у нас состояние привязано к http-сессии
1. нажать undo
2. открыть тоже самое, но еще одной вкладкой (с тем же только url-ом, или с тем же состоянием страницы)
3. выполнить ту же самую последовательность нажатий кнопок, что и при открытии первой страницы
Как ты этот сценарий реализуется той схемой, которую ты написал вначале треда? Через фаулеровское "Сохранение состояния в базе"?ajax вытягивает данные в браузер,
они там редактируется пользователем,
ajax подкрашивает пользователю правильность изменений,
по кнопке "применить изменения", изменение передается на сервер, где еще раз проверяется на валидность и сохраняется в базе.
но в том, что я писал - это не есть бизнес-транзакция, это есть незаконченная ветка.ты уже определись либо ты не понимаешь, тогда ты не можешь утверждать "это не есть бизнес-транзакция".
Либо твое мнение — "это не есть бизнес-транзакция". Тогда твое мнение ошибочно.
ajax вытягивает данные в браузер,так теперь уже ajax
они там редактируется пользователем,
ajax подкрашивает пользователю правильность изменений,
по кнопке "применить изменения", изменение передается на сервер, где еще раз проверяется на валидность и сохраняется в базе.
. Продолжаешь демонстрировать свою некомпитентность в обсуждаемых технологиях. Ты в курсе основ работы майкрософтовского ajax-фрайворка?ты уже определись либо ты не понимаешь, тогда ты не можешь утверждать "это не есть бизнес-транзакция".дело в том, что не важно - бизнес-транзакция это или нет, главное - что это не законченная ветка.
Либо твое мнение — "это не есть бизнес-транзакция". Тогда твое мнение ошибочно.
дело в том, что не важно - бизнес-транзакция это или нет, главное - что это не законченная ветка.что тебе мешает считать это незаконченной бизнес-транзакцией?
так теперь уже ajax . Продолжаешь демонстрировать свою некомпитентность в обсуждаемых технологиях. Ты в курсе основ работы майкрософтовского ajax-фрайворка?хмм, ты отстаешь от mainstream лет на 5
http://blogs.visoftinc.com/archive/2009/04/28/ASP.NET-4.0-AJ...
что тебе мешает считать это незаконченной бизнес-транзакцией?так что такое тогда бизнес-транзакция?
это действия пользователя до нажатия на кнопку save?
или все-таки что-то другое?
если другое, то что?
хмм, ты отстаешь от mainstream лет на 5ага с учетом даты новости
http://blogs.visoftinc.com/archive/2009/04/28/ASP.NET-4.0-AJ...
4/28/2009 12:21:39 AMThis is the new release of the Microsoft AJAX Framework that will be released with ASP.NET 4.0. ... Keep in mind that these components are still in "preview" mode (meaning no Microsoft support though they are usable at your own risk.
ага с учетом даты новости 4/28/2009 12:21:39 AMтак речь о том, что так надо строить web приложения появилась еще до .net 3.5.
соответственно в /net 3.5 появился wcf, который позволял этот подход прозрачно поддержать на стороне сервере, в 4.0 появился встроенная поддержка и на стороне клиента.
так речь о том, что так надо строить web приложения появилась еще до .net 3.5.ага давай еще отсчитывать от появления xmlhttprequest-а, или лучше вообще от появления ifram-ов.
соответственно в /net 3.5 появился wcf, который позволял этот подход прозрачно поддержать на стороне сервере, в 4.0 появился встроенная поддержка и на стороне клиента.
это действия пользователя до нажатия на кнопку save?вот это
4.0 появился встроенная поддержка и на стороне клиента.а теперь давай спросим у топикстартера о какой версии ASP.NET шла речь?
а теперь давай спросим у топикстартера о какой версии ASP.NET шла речь?этот подход хоть на asp.net 1.0 можно реализовывать...
этот подход хоть на asp.net 1.0 можно реализовывать...об этом я и говорю, но когда без уточнений говорят ASP.NET имеют ввиду другое. Особенно с учетом того, что в первом посте говориться о виюстейте.
ajax вытягивает данные в браузер,Ладно про ajax это был шаг в сторону, проблема никуда не исчезает. В этом случае состояние находятся в Data Transfer Object-ах. Т.е. мы приходим к сценарию smart client-а. ... скоро продолжим
они там редактируется пользователем,
ajax подкрашивает пользователю правильность изменений,
по кнопке "применить изменения", изменение передается на сервер, где еще раз проверяется на валидность и сохраняется в базе.
В этом случае состояние находятсякстати что ты понимаешь под состоянием?
значения трех полей которые ввел пользователь? что-то еще?
кстати что ты понимаешь под состоянием?Давай иметь ввиду упомянутый мной пример. Там коллекции есть.
значения трех полей которые ввел пользователь? что-то еще?
Давай иметь ввиду упомянутый мной пример. Там коллекции есть.там use case-ов нет.
там use case-ов нет.согласен, но скриншоты выложить не могу, поскольку это собственность фирмы. Представь, что все эти сущности редактируются на одной большой форме. Пользователь воспринимает ее как один документ. И это действительно документ, он распечатывается на бумаге и по нему проходят деньги
.т.е. состоянием является один введенный пользователем "лист экселя"?
например, графический редактор:как раз это к рассматриваемой проблеме не имеет прямое отношение. Вот, если бы он, выкладывал бы подготовленный документ на какой-нибудь SharePoint.
делаем ветку в память (оставляя основной мир на диске
далее все действия применяем сразу на локальный мир с возможностью отката,
интегрируем полученное изменение с версией на диске (интеграция простая - в виде перезаписи всего).
т.е. состоянием является один введенный пользователем "лист экселя"?не понял
Excel плоский, в примере не плоская структура
Оставить комментарий
agaaaa
Что-то чтение интернетов не помогает разобраться с тем, как подружить ORM'ы с ASP.NETВ случае с DataSet'ами и DataAdapter'ами всё просто. Есть отключенный DataSet, сериализованный во ViewState страницы. Пользователь что-то меняет, жмакает "Сохранить" и данные заливаются в БД через DataAdapter.Update
Что делать с контекстами в ORM'ах? Они не сериализуются и поэтому не могут сами по себе использоваться на странице по аналогии с DataSet. Подсоединение и отсоединение сущностей нужно реализовывать на каждой странице, что накладно с точки зрения труда программиста.
Вопрос: можно ли их как-нибудь с малыми затратами труда подружить какой-нить ORM и ASP.NET?