Здравствуйте, IT, Вы писали:

_FR>>Сдаюсь! Набрать быстрее . Но, может, болезнь у меня такая но пора бы уже, имея такой инструмент, как .NET, набирать меньше. Работу со схемой и объяснить проще\нагляднее,

IT>В VS 2005 будут диаграммы классов.

Пока не имел удовольствия видеть, но схема вроде как сама строится, а диаграмму классов... ну да ладно, не буду о том, что не видел.
Да и по любому, на схему приятно\полезно любоваться. Я, например, в ЕМ схемы не рисую — наши базы создаём из скрипта, и схемы, ясное дело, идут лесом.

_FR>>и на схему можно "перетащить" таблицу из "Server Explorer" (и несколько таблиц пачкой, вместе со связями),

IT>Вот! Единственная фича, которая чего-то стоит. Пока я обхожусь копи-пейстом из Enterprise Manager. Но для этого и свою собственную перетягивалку не жалко написать

_FR>>и... ну, я считаю эстетичнее

IT>Эстетичнее найдя ошибку в дебагере тут же её исправить, а не бежать в схему, править её и потом перегенерировать класс. Эстетичнее всё иметь компактно и в одном месте. К тому же намного гибче, т.к. ты ничем не ограничен вообще. В случае с генератором ты ограничен возможностями генератора.

А откуда ошибки в простом объявлении абстрактного класса? Скорее всего связаны с неправильным мапом на БД... И логичнее их в схеме править.

Здравствуйте, IT, Вы писали:

_FR>>Сдаюсь! Набрать быстрее . Но, может, болезнь у меня такая но пора бы уже, имея такой инструмент, как .NET, набирать меньше. Работу со схемой и объяснить проще\нагляднее,

IT>В VS 2005 будут диаграммы классов.

_FR>>и на схему можно "перетащить" таблицу из "Server Explorer" (и несколько таблиц пачкой, вместе со связями),

IT>Вот! Единственная фича, которая чего-то стоит. Пока я обхожусь копи-пейстом из Enterprise Manager. Но для этого и свою собственную перетягивалку не жалко написать

CodeSmith Вам в помощь.

Здравствуйте, _FRED_, Вы писали:

_FR>А откуда ошибки в простом объявлении абстрактного класса? Скорее всего связаны с неправильным мапом на БД... И логичнее их в схеме править.

Неправильный мап, какой-нибудь конфликт с предком, необходимость добавить setter, да мало ли что. Хотя, если не добавлять свою логику в классы, то таких случаев не должно быть много. Но тогда, как я уже сказал, в них полностью теряется смысл.

Здравствуйте, G2, Вы писали:

IT>>Вот! Единственная фича, которая чего-то стоит. Пока я обхожусь копи-пейстом из Enterprise Manager. Но для этого и свою собственную перетягивалку не жалко написать

G2>CodeSmith Вам в помощь.

Он из MS SQL может структуру таблиц вытягивать? К тому же за него денежку надо платить.

Здравствуйте, IT, Вы писали:

IT>Он из MS SQL может структуру таблиц вытягивать?
По описанию должен.
IT>К тому же за него денежку надо платить.
Trial 30 дней, думаю его достаточно будет.

Здравствуйте, G2, Вы писали:

G2>Здравствуйте, _FRED_, Вы писали:

_FR>>Да, для обмена лучше использовать одно представление, для показа — другое, а для рассчётов — третье Остаётся их только подружить и не запутаться во взаимоотношениях.

G2>Интересно сделано в WeFly247(демонстрационное приложение к Whidbey Beta 2), там не стали делать один typedDataSet со связями, а просто нагенерили датасетов по принципу один typedDataSet представляет одну Business Entity.

Да и раньше (в 2003 Студии) приходилось делать точно также. Именно поэтому я с нетерпением ожидал появления типизированных датаадаптеров для DataTable и возможности создания типизированых DataTable. Результаты немного разочаровали — но все-же лучше, чем было ранее

Здравствуйте, Andy Panda, Вы писали:

AP>Да и раньше (в 2003 Студии) приходилось делать точно также. Именно поэтому я с нетерпением ожидал появления типизированных датаадаптеров для DataTable и возможности создания типизированых DataTable. Результаты немного разочаровали — но все-же лучше, чем было ранее

Я связи делал, у меня все business entities в одном *.xsd файле были.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, G2, Вы писали:

IT>>>Вот! Единственная фича, которая чего-то стоит. Пока я обхожусь копи-пейстом из Enterprise Manager. Но для этого и свою собственную перетягивалку не жалко написать

G2>>CodeSmith Вам в помощь.

IT>Он из MS SQL может структуру таблиц вытягивать? К тому же за него денежку надо платить.

А это смотрел?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, GlebZ, Вы писали:

IT>>>Т.е. все возможные комбинации?
GZ>>Ага

IT>Да уж. Ты опять мне приводишь крайний отмороженный случай Мне сказать больше нечего

В Российской действительности эти отмороженные случаи встречаются на каждом шагу.

Здравствуйте, kig, Вы писали:

kig>В Российской действительности эти отмороженные случаи встречаются на каждом шагу.
Отмороженные случаи — вопрос международный. Нужно просто глянуть на Outlook.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, IT, Вы писали:

IT>>датасеты вырываются далеко вперёд в том что касается чтения данных из БД и баиндинга этих данных на формы. Если решить эти две проблемы, датасеты однозначно проигрывают бизнес-объектам.
GZ>Решить эти проблемы легко. Их и за проблемы то считать не стоит, неделя работы для простейших случаев. Проблема — DataView. Повторить его функциональность уже значительно сложней.

К сожалению, я не нашел простого и быстрого способа байндить грид к иерархической коллекции объектов. Да еще с возможностью редактирования. Сделать, конечно, можно все, но получается в итоге, что-то типа того же датасета

Здравствуйте, GlebZ, Вы писали:

kig>>В Российской действительности эти отмороженные случаи встречаются на каждом шагу.
GZ>Отмороженные случаи — вопрос международный. Нужно просто глянуть на Outlook.

Что не так с моей любимой программой??

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, GlebZ, Вы писали:

kig>>>В Российской действительности эти отмороженные случаи встречаются на каждом шагу.
GZ>>Отмороженные случаи — вопрос международный. Нужно просто глянуть на Outlook.

_FR>Что не так с моей любимой программой??
Перевести на RFD с его группировкой поиском и фильтрацией Microsoft'у обойдется дороже.

С уважением, Gleb.

Здравствуйте, olegkr, Вы писали:

O>К сожалению, я не нашел простого и быстрого способа байндить грид к иерархической коллекции объектов. Да еще с возможностью редактирования. Сделать, конечно, можно все, но получается в итоге, что-то типа того же датасета
Скорее как раз DataView. DataView в общем случае содержит ссылки на объекты, а не сами объекты.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

kig>>>>В Российской действительности эти отмороженные случаи встречаются на каждом шагу.
GZ>>>Отмороженные случаи — вопрос международный. Нужно просто глянуть на Outlook.

_FR>>Что не так с моей любимой программой??
GZ>Перевести на RFD с его группировкой поиском и фильтрацией Microsoft'у обойдется дороже.

Да ну, в пропертигриде нормально работает группировка по свойствам... Тут вопрос скорее в реализации коллекций, в которых хранятся элементы. Но да, это уже скорее "прикрутка". Для "группировки поиска и фильтрации" таблица самое оно, да + возможность сохранения при изменении оригинальной версии и + информации об ошибке в поле...
Но придумать адекватное, не кажующееся не родным, решение этих вопросов в иерархии объектов... занятие очень исследовательское

Здравствуйте, _FRED_, Вы писали:

_FR>Да ну, в пропертигриде нормально работает группировка по свойствам... Тут вопрос скорее в реализации коллекций, в которых хранятся элементы. Но да, это уже скорее "прикрутка". Для "группировки поиска и фильтрации" таблица самое оно, да + возможность сохранения при изменении оригинальной версии и + информации об ошибке в поле...
_FR>Но придумать адекватное, не кажующееся не родным, решение этих вопросов в иерархии объектов... занятие очень исследовательское
Ну-ну. Практики типа Document-View не знаю кто придумал, но сделал это ну очень давно. И чтобы сделать подобный (может быть и helper) класс, и чтобы он при этом не был родным, очнь трудная задача. К тому же никаких технологических проблем при этом я не вижу. Можно сказать что они уже есть. Просто если делать слишком серьезно (как это сделано в DataView) то писанины будет очень много. Такой легкий XPath получится.

С уважением, Gleb.

Здравствуйте, IT, Вы писали:

IT>Хорошее решение должно порождать простой прикладной код. Поэтому можно всегда сравнить два подхода просто написав на них одну и ту же задачу. Где прикладной код будет проще — то решение лучше. Если рассматривать датасеты vs бизнес-объекты в рамках стандартных средств, то проигрывая бизнес-объектам в простоте написания бизнес логики, датасеты вырываются далеко вперёд в том что касается чтения данных из БД и баиндинга этих данных на формы. Если решить эти две проблемы, датасеты однозначно проигрывают бизнес-объектам.

Как в таком случае работать правильнее в случае наличия дочерних таблиц.
На данный момент CRUD в случае наличия дочерних таблиц я делаю в хранимых процедурах,

ALTER PROCEDURE dbo.AddPatient 
(
    @PatientID int OUTPUT,
    @FirstName nvarchar(50),
    @MiddleName nvarchar(50),
    @LastName nvarchar(50),
    @Address ntext,
    @Phone nvarchar(25),
    @JobTitle nvarchar(50),
    @Gender bit,
    @Age smalldatetime,
    @DrID int,
    @StartTimeStamp smalldatetime
)     
AS 

 BEGIN TRAN AddPatient

INSERT INTO Patients
(
    FirstName, 
    MiddleName, 
    LastName, 
    Address, 
    Phone,
    JobTitle,
    Gender,
    Age    
)
VALUES 
(
    @FirstName,
    @MiddleName,
    @LastName,
    @Address,
    @Phone,
    @JobTitle,
    @Gender,
    @Age    
)

SELECT @PatientID = SCOPE_IDENTITY()

EXEC AddExamination @DrID, @PatientID, @StartTimeStamp

COMMIT TRAN AddPatient


ALTER PROCEDURE dbo.AddExamination 
(
    @DrID int,
    @PatientID int,
    @StartTimeStamp smalldatetime
)

AS

INSERT INTO  Examinations
(
    DrID,
    PatientID,
    StartTimeStamp
)
VALUES 
(
    @DrID,
    @PatientID,
    @StartTimeStamp
)

м.б. это правильнее делать на другом уровне — BLL или DAL.

Я также храню в business entity Patient поле типа DataSet для хранения дочерней таблицы Examination.

 private DataSet _examinations;

Эх, хорошо бы посмотреть на реальный грамотный проект.

Здравствуйте, G2, Вы писали:

G2>Как в таком случае работать правильнее в случае наличия дочерних таблиц.
G2>На данный момент CRUD в случае наличия дочерних таблиц я делаю в хранимых процедурах,

А что ты собираешься делать, если у тебя будет два дочерних объекта (транзакцию ты уже закрыл). Или ни одного (параметры для дочерней записи у тебя не могут быть NULL)?

В случае с MS SQL можно использовать два способа:

1. Сделать два спрока. Один для добавления мастер-записи, второй для добавления дочерних. Транзакцию в данном случае контролирует BL. Сначала добавляется мастер-рекорд, затем в цикле все дочерние. Основным недостатком здесь является наличие дополнительных раундтрипов на сервер при добавлении дочерних записей. Поэтому, нужно смотреть как часто выполняется такие операции и не просадит ли это сервер и сетевой трафик. Достоинтсва — относительная простота SQL кода.

2. Использовать XML. В этом случае используется один спрок, которому в качестве параметра передается XML строка, содержащая все необходимые данные. Достоинства — только один вызов сервера, недостатки — некоторое усложнение как самой сохранённой процедуры, так и BL кода, который должен сформировать XML.

G2>ALTER PROCEDURE dbo.AddPatient 
(
 ...
    @Gender bit,
 ...
AS

То что Gender может принимать только два значения — это большая ошибка
Мой прошлый проект был биллинг системой для докторов по заказу Pfizer (это контора, которая виагру придумала ). Так вот там мы использовали для Gender следующий энумератор:

public enum Gender
{
    Unknown,
    Male,
    Female,
    Other
}

Я долго ржал, но это факт.

G2>SELECT @PatientID = SCOPE_IDENTITY()

Вместо output параметра удобнее использовать SELECT, т.е. в конце спрока нужно было бы сделать

SELECT @PatientID

Тогда, например в ADO.NET, это свелось бы к вызову ExecuteScalar, что намного проще обработки output параметра.

G2>Я также храню в business entity Patient поле типа DataSet для хранения дочерней таблицы Examination.

Почему не хранить просто коллекцию объектов? Получается несколько нелогично.

G2>Эх, хорошо бы посмотреть на реальный грамотный проект.

На реальный проект тебе никто не даст посмотреть. А вот более менее реальный пример сделать можно было бы. Но здесь есть одно большое НО!. Помидорами тухлыми закидают через две секунды. У нас же кругом одни наполеоны, поэтому опасно это А вообще, если набить руку и определится с приоритетами, то три слоя BL, DAL и DB можно свести к довольно примитивной вещи.

Здравствуйте, IT, Вы писали:

IT>1. Сделать два спрока.

Хранимая процедура?

IT>Один для добавления мастер-записи, второй для добавления дочерних. Транзакцию в данном случае контролирует BL. Сначала добавляется мастер-рекорд, затем в цикле все дочерние. Основным недостатком здесь является наличие дополнительных раундтрипов на сервер при добавлении дочерних записей.

Это означает "обращение к серверу"?

IT>2. Использовать XML. В этом случае используется один спрок, которому в качестве параметра передается XML строка, содержащая все необходимые данные. Достоинства — только один вызов сервера, недостатки — некоторое усложнение как самой сохранённой процедуры, так и BL кода, который должен сформировать XML.

Кажется, имеется ограничение на размер такого поля в 4000 символов nvarchar?

IT>То что Gender может принимать только два значения — это большая ошибка
IT>Мой прошлый проект был биллинг системой для докторов по заказу Pfizer (это контора, которая виагру придумала ). Так вот там мы использовали для Gender следующий энумератор:

IT>public enum Gender
IT>{
IT>    Unknown,
IT>    Male,
IT>    Female,
IT>    Other
IT>}

IT> Я долго ржал, но это факт.

Из своего скромного опыта добавлю к этому интересному списку значение "Сhild"

G2>>SELECT @PatientID = SCOPE_IDENTITY()

IT>Вместо output параметра удобнее использовать SELECT, т.е. в конце спрока нужно было бы сделать

IT>SELECT @PatientID

IT>Тогда, например в ADO.NET, это свелось бы к вызову ExecuteScalar, что намного проще обработки output параметра.

Ну, если прям из прикладного кода обращаться процедурам, то возможно, а так это прекрасно разруливается уровнем выше и даёт, так же возможность получения некоторой информации о результате работы. У себя в возвращаемом значении везде коды возврата указываю коды возврата.

Здравствуйте, _FRED_, Вы писали:

_FR>Это означает "обращение к серверу"?
Да.

_FR>Кажется, имеется ограничение на размер такого поля в 4000 символов nvarchar?
2Гб
Слышал про реальный проект, где таким способом заносилось по 60-80 метров данных, и ничего, оказалось довольно жизнеспособно... Хотя это конечно уже на любителей.