| Вопрос: Получение значения автоинкримента | Добавлено: 24.10.05 16:35 |
Автор вопроса:  piton | ICQ: 315928410 |
| Ответы | Всего ответов: 25 |
|
Номер ответа: 16 Автор ответа:  piton ICQ: 315928410 Вопросов: 7 Ответов: 11 |
Профиль | | #16 | Добавлено: 25.10.05 12:26 |
|
по поводу поставленной задачи:
имеется две таблицы в которых реализовано отношение многие ко многим, используя третью связующую таблицу. Так вот, когда добавляем запись в первую таблицу, то необходимо произвести связь с другой таблицей по ID. Если у кого есть предложения как это можно реализовать по другому, то буду очень благодарен за помощь |
||
|
Номер ответа: 17 Автор ответа: pitonICQ: 315928410 Вопросов: 7 Ответов: 11 |
Профиль | | #17 | Добавлено: 25.10.05 12:27 |
| база MS SQL Server 2000 | ||
|
Номер ответа: 18 Автор ответа: Павел Администратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #18 | Добавлено: 25.10.05 18:28 |
|
Элементарный пример.
Есть сущность "статья". В слое бизнес-логики представлена в виде класса Article, имеющего помимо прочих свойства, скажем, Title и Text. Для хранения статей создана таблица Articles: ID int Identity PK Title nvarchar(256) Text ntext Нужно произвести элементарные CRUD операции. Положим, создание объекта без использования ID особых проблем не приносит... Хотя тоже может оказаться проблематичным при некоторых постановках задачи. Итак, первое задание по вышеуказанным данным: Юзеру выводится список статей в базе, он выбирает одну из них, нажимает "Редактировать", в открывшейся форме изменяет значения полей Title и Text, жмет "Сохранить" и данные сохраняются в базе. Правильно ли я понимаю, что ты предлагаешь это решить, вообще не используя значение поля ID в классах бизнес-логики? Мое решение (с использованием ID внутри классов слоя бизнес-логики и классов слоя преобразователя данных) таково: 1. В классе Article определяем ReadOnly свойство ID. 2. Формирую коллекцию объектов Article, заполняя у них свойства ID, Title, по такому SQL-запросу: SELECT ID, Title FROM Articles 3. Вывожу список на страницу (с помощью DropDownList, скажем), так, что в элементе списка отображается значение свойства Title, а значение элемента - поле ID. 4. При клике "Редактировать" смотрю SelectedValue у списка, получаю исходя из этого ID нужную запись и формирую из нее объект, заполняя все его свойства. SQL-запрос: SELECT ID, Title, Text FROM Articles WHERE ID = @ID 5. Вывожу в форме старые значения свойств Title, Text. В ViewState("EditedArticeID"  пишу значение свойства ID.
6. При клике на "Сохранить" смотрю значение ViewState("EditedArticeID" , загружаю из БД объект по этому ID,
изменяю его свойства надлежащим образом: Article.Title = ArticleTitle.Text Article.Text = ArticleText.Text Сохраняю новые значени в БД следующим запросом: UPDATE Articles SET Title = @Title, Text = @Text WHERE ID = @ID Дальше по жалению можно юзера отфорвардить на страницу просмотра статьи, благо ID известен. В вышеуказанном коде ID используется для однозначной идентификации объекта во всех слоях приложения: в БД он идентифицирует запись, в слое логики идентифицирует экземпляр класса Article, в слое представления указывает, какой именно объект редактирует поьзователь. В то же время, пользователю ID абсолютно пофик. В вышепривеенной схеме он его никогда не увидит, если только не полезет смотреть сгенерированный HTML. Примечание: Я тут не указывал, что в каком слое производится. Собственно, взаимное отображение данные БД <-> объект предметной области (и, собственно, весь ко обращения к БД) лежит в слое преобразователя данных. Все формочки, пимпочки, связь элементов с данными и т.д. - в слое представления. Но это, думаю, к делу отношения не имеет. |
||
|
Номер ответа: 19 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #19 | Добавлено: 25.10.05 18:35 |
|
Кстати, я как-то склонен больше доверять не "одному человеку", а
признанному знатоку в области проектирования крупных корпоративных приожений Мартину Фаулеру, который ничего зазорного в использовании ID для идентификации объектов внутри слоя бизнес-логики. |
||
|
Номер ответа: 20 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #20 | Добавлено: 25.10.05 18:41 |
|
Да, кстати.. Не воспринимай это как наглые выпады против твоей точки
зрения. Просто я решительно не понимаю, как можно обойтись без использования значений PK в приложении, и хочу понять.. А-то вдруг на самом деле я сам себе злобный буратино?
|
||
|
Номер ответа: 21 Автор ответа: GSergВопросов: 0 Ответов: 1876 
|
Профиль | | #21 | Добавлено: 25.10.05 19:53 |
|
Правильно ли я понимаю, что ты предлагаешь это решить, вообще не используя значение поля ID в классах бизнес-логики?
Да ни в коем разе. Когда мы выбираем по некоторым бизнес-признакам запись и берём уже имеющееся (и заданное не нами, а базой) значение первичного ключа для того, чтобы осуществлять операции с этой строкой, то всё это правильно. И это не есть "завязывать бизнес-логику на первичный ключ". Ты никогда не сталкивался с людьми, которые очень хотят после удаления строки из базы перенумеровать счётчик так, чтобы дырок не было, потому что иначе у них там что-то ползёт где-то? И им все дружно предлагают сносить всё поле, а потом добавлять его заново - или через временную таблицу? Вот это завязывание логики на первичный ключ. |
||
|
Номер ответа: 22 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #22 | Добавлено: 25.10.05 20:00 |
|
With NewRow
.Edit !Field1="Вася" !Field2="Пупкин" RetVal=!ID .Update End with Это работает. Сказал, что не работает, потому что по поводу этой конструкции у меня были какие-то неприятные воспоминания, которые обычно в случае неработы бывают. Порылся в исходниках - один из моих проектов был целиком на хранимых процедурах, но в одном-единственном месте пришлось делать так. Поэтому осталось неприятное впечатление. |
||
|
Номер ответа: 23 Автор ответа: EROSВопросов: 58 Ответов: 4255  |
Профиль | | #23 | Добавлено: 25.10.05 21:25 |
|
GSerg, эта конструкция не может не работать. Проверено на mdb-базах десятки раз и через DAO и через ADO. Не берусь судить о SQL-базах. Хотя могу предположить,что и там он будет работать вполне корректно по той простой причине,что как только новую строку переводишь в состояние Edit, всем полям, у которых определено значение Default присваиваются эти значения. То же самое,по моему мнению, происходит и с полем автоинкремента.
Тут все же возможен прокол при работе с отсоедененными наборами данных. Но поскольку мы имеем ссылку на новую строку,то св-во ID можно будет считать уже после создания новой строки,редактирования и добавления в БД. |
||
|
Номер ответа: 24 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #24 | Добавлено: 25.10.05 22:54 |
| Я же говорю - работает, работает... | ||
|
Номер ответа: 25 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #25 | Добавлено: 26.10.05 11:48 |
| А, ну тогда всё, я с тобой согласен. | ||