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

S>Но до сих пор не могу решить, что лучше использовать в качестке Buisness Entities, толи типизированные DataSet, генерируемые студией + генерируемые SqlDataAdapter, толи свои классы, поражденные от DataSet + свои хранимые процедуры.

S>Собственно инетерсно было бы узнать, как такие приложения разрабатывает народ. Поделитесь опытом плиз.

Самым неправильным решением было бы использование только датасетов или только бизнес объектов. И то и другое имеет свои достоинства и преимущества, соответственно и применять их нужно там где это целесообразно.

Достоинства датасетов определяются тем, что это фактически маленькая база данных со всеми вытекающими последствиями:

— наличие связей между сущностями, что позволяет, например, не заботиться об удалении подчинённых записей, достаточно удалить мастер-рекорд.
— проверка ограничений, как по связям, так и по некоторым значениям полей (что иногда как раз можно назвать недостатком).
— наличие графических средств редактирования с возможностью автогенерации кода.
— сохранение внутреннего состояния датасета (информация об удалённых и изменённых записях, возможность отката). Весьма большой плюс.
— поддержка со стороны ADO.NET (DataAdapter), что позволяет одним вызовом вносить все изменения в базу.
— поддержка со стороны визуальных средств (хотя типизированные коллекции тоже довольно легко прикручиваются, но о поддержки связей между сущностями речи не идёт).

Недостатков к сожалению тоже хватает, причём многие из них являются обратной стороной медали достоинств:

— невозможность расширения датасетов своей функциональностью. Иногда хотелось бы добавить пару вспомогательных методов в row или table, но так как они глубоко упрятаны в датасет, то остаётся только курить бамбук вместе с ООП в лице инкапсуляции.
— отсутвие поддержки перечислителей, соответственно абстракция от структуры данных тоже идёт лесом. Использование захаркоженных значений расползается по системе, в результате чего их потом приходится ловить и давить как тараканов. Весьма большой минус.
— избыточная сериализация (в любой датасет всегда включается его схема).
— отсутсвие бинарной сериализации, что может увеличить трафик в разы.
— слабое повторное использование сущностей и как следствие тотальное дублирование. Можно конечно сделать xsd шаблоны и прикрутить import, но на этом как правило речь о визуальных средствах разработки заканчивается, рукова закатываются по самые уши и поехали выпиливать xsd схемы в рукопашную.

Бизнес объекты как правило лишены перечисленных недостатков, но очень часто и достоинств Большинство вещей приходится делать ручками, в частности больше всего напрягает вычитывание записей из рекордсета и маппинг. Если решить эти проблемы, то всё совсем не так уж плохо С другой стороны бизнес объекты несравненно гибче, их возможности фактически ограничены только высотой полёта твоей фантазии.

Из всего выше сказанного можно сделать следующий вывод — однозначного ответа нет

Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.

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

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

G2>Из — за их тяжеловесности?

Я бы сказал из-за громоздкости.

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

Здравствуйте, 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 можно свести к довольно примитивной вещи.

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

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

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

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

IT>>Какое извращение
S>Я бы постеснялся называть способ, приводящий для типичных мастер/деталь к 10кратному росту производительности по сравнению с одиночными запросами и к 10кратному снижению потребляемой серверным процессом памяти по сравнению с парсингом XML извращением

Так никто и не спорит. Но для того чтобы попасть из разряда извращений в копилку разработчика нужно всё это доказать. Вон Merle уже говорит, что не в 10, а всего лишь в 5
А вообще надо будет нашего DB архитектора попытать на эту тему. Чувак из MS и во всю двигает XML подход, интересно что он на это скажет

IT>>Если и сложнее, то не намного.
S>В принципе да. Слабо изобрести интерфейс StatementBatch с поддержкой зависимостей между стейтментами? Чтобы все не хуже, чем в обычных SqlCommand. Я вот так сходу чтой-то стесняюсь.

Какой ещё интерфейс? Тут надо просто пару хелперов нарисовать.

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

IT>- невозможность расширения датасетов своей функциональностью. Иногда хотелось бы добавить пару вспомогательных методов в row или table, но так как они глубоко упрятаны в датасет, то остаётся только курить бамбук вместе с ООП в лице инкапсуляции.

В VS2005 можно

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

В VS2005 можно (не знаю, может даже в VS2003 тоже)

IT>- избыточная сериализация (в любой датасет всегда включается его схема).

сериализовать можно и без неё

<?xml version="1.0" standalone="yes"?>
<atm:InfrastructureDataSet xmlns:atm="urn:digiton-atm/infrastructure">
  <Radios xmlns="urn:digiton-atm/infrastructure">
    <RadioID>f3837198-d4a1-405a-9556-7923bc65ec87</RadioID>
    <RadioName>13</RadioName>
  </Radios>
  <Radios xmlns="urn:digiton-atm/infrastructure">
    <RadioID>28b2bd1f-dfcf-496c-87f8-f8b762f8df8d</RadioID>
    <RadioName>dio3</RadioName>
  </Radios>
  <Packs xmlns="urn:digiton-atm/infrastructure">
    <PackID>dd677ad6-d008-4250-9189-055a9111c71b</PackID>
    <RadioID>f3837198-d4a1-405a-9556-7923bc65ec87</RadioID>
    <PackName>Test</PackName>
    <UserPos>1</UserPos>
    <UserHide>false</UserHide>
  </Packs>
  <Packs xmlns="urn:digiton-atm/infrastructure">
    <PackID>05abaeb6-3f18-4deb-8eec-9781441c5d91</PackID>
    <RadioID>f3837198-d4a1-405a-9556-7923bc65ec87</RadioID>
    <PackName>Pack1</PackName>
    <UserPos>1</UserPos>
    <UserHide>false</UserHide>
  </Packs>
</atm:InfrastructureDataSet>

IT>- отсутсвие бинарной сериализации, что может увеличить трафик в разы.

В VS2005 можно

IT>- слабое повторное использование сущностей и как следствие тотальное дублирование. Можно конечно сделать xsd шаблоны и прикрутить import, но на этом как правило речь о визуальных средствах разработки заканчивается, рукова закатываются по самые уши и поехали выпиливать xsd схемы в рукопашную.

IT>Из всего выше сказанного можно сделать следующий вывод — однозначного ответа нет

У меня две параллельных модели, причём сущности загружаются из таблицы (то есть датасет первичен), — берём таблицу типизированного датасета и получаем массив сущностей, со своей, немного навороченной (в некоторых местах) обработкой свойств (например, если поле Age должно быть положительным).
Единственное, что здесь надо решить — генерацию кода этих самых сущностей. пока руками (в виду первой беты студии), а потом на R#, например. Процесс совсем не сложный, а плюсы обоих подходов радуют.

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

IT>>- отсутвие поддержки перечислителей, соответственно абстракция от структуры данных тоже идёт лесом. Использование захаркоженных значений расползается по системе, в результате чего их потом приходится ловить и давить как тараканов.
M>Что такое перечислители и захаркоженные значения?

Есть таблица:

CREATE TABLE Users (
  UserID           int IDENTITY(1,1)   NOT NULL,
  ---------------------------------------------
  UserName         nvarchar(255)       NOT NULL,
  UserPassword     nvarchar(255)       NOT NULL,
  ---------------------------------------------
  UserKind         tinyint             NOT NULL, -- 1: Admin, 2: User, 3: Reader
  ---------------------------------------------
  CONSTRAINT PK_Users PRIMARY KEY CLUSTERED (UserID),
  CONSTRAINT UK_Users UNIQUE (UserName),
  CONSTRAINT CK_Users CHECK(len(UserName) > 1)
)
GO

Поле UserKind которой может принимать одно из следующих значений:

  public enum  UserKind : byte { // Это и есть перечислитель (byte - это tinyint в MSSQL)
    Admin = 1,
    User,
    Reader,
  }

Если механизм загрузки объектов из БД может их загрузить лишь в такой класс:

  public class User
  {
    public int ID;
    public string Name;
    public string Password;
    public byte Kind;
  }

То экземплярам класса User придётся в поле Kind проставлять "захаркоженные значения":

  User user = new DatabaseManager.GetUser(1);
  user.Kind = 2; // - вот это "захаркоженное значение"
  // Тут конечно можно и user.Kind = (bype)UserKind.User;, но некрасиво, да и на элемент управления такое поле просто не забиндить
  DatabaseManager.UpdateUser(user);

Более грамотный DatabaseManager сможет вернуть такой класс:

  public class User
  {
    public int ID;
    public string Name;
    public string Password;
    public UserKind Kind;
  }

Проведя преобразование tiniint->UserKind у себя внутри. И тогда всё красивее:

  User user = new DatabaseManager.GetUser(1);
  user.Kind = UserKind.User;
  DatabaseManager.UpdateUser(user);

M>Как я понял, захаркоженные значения — это что-то типа

M>TableX.Fields["Age"].GetValue();

M>А есть способы избежать этого? Эти самые загадочные перечислители?
Да, объявляя "Age" как константу, как-то так, например:

  public static class DatabaseFields
  {
    public static class TableX
    {
      public const string Age = "Age";
    }
  }
  // ...
  // Использование
  TableX.Fields[DatabaseFields.TableX.Age].GetValue();

Но, что-то я такого пока не видел.

IT>>Бизнес объекты как правило лишены перечисленных недостатков, но очень часто и достоинств Большинство вещей приходится делать ручками, в частности больше всего напрягает вычитывание записей из рекордсета и маппинг. Если решить эти проблемы, то всё совсем не так уж плохо
M>А это что-за звери? Поиск бизнес объектов в списке что-ли?

Маппинг — вычитывание данных из рекордсета и простановка значений полей строки полям экземпляра класса. Посмотреть пример можно здесь

Автор(ы): Игорь Ткачёв
Дата: 01.07.2003
В статье подробно рассматривается состав и способы применения пространства имён Rsdn.Framework.Data, представляющего собой высокоуровневую обёртку над ADO.NET.

.

M>PS
M>В проектировании я вообще-то чайник, но кошмар с табличками/датасетами уже достал. Присматриваюсь к бизнес-объектам, но пугает большой (ИМХО) объём рутинной работы.

Смотри RFD (Rsdn.Framework.Data) — процентов 50 а то и много больше, в простых случаях, уже сделали и отладили.

А>Дайте ,плиз, линки кто чем пользовался.
Что видел и пробывал:
1.Mongoose Objectz.NET пользую сейчас, есть пара особо зверских багов, но терпимо. Есть free лицензия.
2.Thona Consulting Object Broker. Особо не смотрел, сразу отпугнула архитектура(бизнес-объекты наследуются от ContextBoundObject). Есть free лицензия.
3.OJB.NET — порт явавского OJB. Выглядит многообещающе, уже даже работает, но статус что-то вроде альфы.
4.MS ObjectSpaces — когда был, теперь уже нет, обещают в составе .NET 2.0 (если вместе с Business Framework — это будет круто)
5.NHibernate — порт с явы, вроде заглох.
Это все честные OR-Mapping tools. Есть еще куча кодогенераторов типа Deklarit, ORM и т.д.

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

G2>Посколько Вы уже отвечали на подобный вопрос хочется уточнить, изменилось ли Ваше мнение по поводу Typed Dataset в связи с выходом VS 2005 и изменеиями в .Net 2.0(partirion class, TableAdapter и т.д).

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

Что касается новой версии датасетов, то я на них ещё не смотрел и пока не горю желанием. С интересом бы сам почитал что-нибудь на эту тему.

Здравствуйте, 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 параметра.

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

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

_FR>>У меня две параллельных модели, причём сущности загружаются из таблицы (то есть датасет первичен), — берём таблицу типизированного датасета и получаем массив сущностей, со своей, немного навороченной (в некоторых местах) обработкой свойств (например, если поле Age должно быть положительным).

IT>Т.е. сначала закачиваешь данные в датасет, а потом переливаешь их в бизнес-объекты?

Да. Закачиваю данные в датасет, потом, где надо (наличие логики на клиенте и некоторые расчёты удобнее вести со своими сущностями, хранящими в себе разные результаты вычислений, имеющие особые арифметические операции) получаю сущности из таблицы или другого набора строк. _По месту_, то есть не храню сущности постоянно, это у меня недолгоживущие объекты.

_FR>>Единственное, что здесь надо решить — генерацию кода этих самых сущностей. пока руками (в виду первой беты студии), а потом на R#, например. Процесс совсем не сложный, а плюсы обоих подходов радуют.

IT>Что именно ты собираешься генерировать?

Классы сущностей. Их должно быть несколько десятков, код у них на 60% одинаков (геттеры-сеттеры свойств, закрузка\сохранение) за небольшими исключениями (типы\имена полей). Каждый класс — partial, то есть каждый можно расширить в зависимости от смысла.

Здравствуйте, IT, Вы писали:
Дело в том, что я стою сейчас перед таким же выбором, только цели у меня учебные. Можно сказать, что собираюсь "стрелять по воробьям из пушки".

IT>Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.

Посколько Вы уже отвечали на подобный вопрос хочется уточнить, изменилось ли Ваше мнение по поводу Typed Dataset в связи с выходом VS 2005 и изменеиями в .Net 2.0(partirion class, TableAdapter и т.д).

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

_FR>Если полностью отказаться от DataSet'ов, то в своём формате (хотя руками и его править неинтересно ), иначе добавить в проект датасет, поменять в нём Custom Tool на прогу, использующую R# и поменять Build Action на Embedded Resource или None.

Т.е. в своей схеме ты собираешься описывать структуру класса, а потом генерировать класс?

1. Чем это принципиально отличается от датасетов? Например, как ты собираешься имплементировать вычисляемые поля типа FullName, если есть FirstName и LastName?
2. Написание абстрактного класса ничем не длиннее. а может быть даже короче и быстрее написания схемы. Т.е. в чём поинт иметь схему в этом случае. Она ничего не упрощает, только усложняет.

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

_FR>Какие возможности бизнес-объектов, которые предоставляет RFD, я могу потерять?

RFD тут не при чём. Потерять ты можешь инкапсуляцию, т.к. сгенерированные классы расширять ты не сможешь. И даже в C# 2.0 partial классы в данном случае будут выглядеть как затычка. Я вообще не понимаю зачем что-то генерить из чего-то, если сам результат по определению можно набить руками быстрее чем нарисовать источник для генерации. Вот скажи мне что быстрее, нарисовать схему и сгенерировать класс или написать:

public abstract class Person
{
    public abstract string FirstName { get; set; }
    public abstract string LastName  { get; set; }
}

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

_FR>Клиент имеет доступ к данным только через процедуры, их вид (сигнатуры) унифицированны, исполняются через одну "дырку". На клиенте проблематично узнать не в строковом виде причину ошибки (кроме строкового параметра raiseerror, а что-то более-менее понятное юзеру сообщить охота.
_FR>В основном, из-за этого.

Понятно. У тебя навороченная серверная логика. Я стараюсь всячески избегать такого подходя.

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

S>Справедливости ради, стоит отметить, что (как минимум для MS SQL) можно обойтись без раундтрипов. Формируем примерно такой батч:

Какое извращение

S>Формировать такой батч несколько сложнее, чем XML, но зато упрощается серверная сторона.

Если и сложнее, то не намного.

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

Я, конечно, приводил пример батча. Но ты почему-то напираешь на то, что генератор батча можно генерировать. Справедливость требует отметить, что классы с разметкой для XML -сериализации генерить еще проще.

kig>Если начинать с нуля генераторы писать, по схеме БД просто так маппинг не сгенерить. По сложной БД. По СП — в лет.
Не, надо наоборот. По схеме генерить классы, мапперы, таблички и SP.
kig>"оформленные атрибутами xml-маппинга" — А какой в них смысл?
Очень простой. Велосипед потому что.
kig>Если уж генерить нормальные орм-классы с полной поддержкой crud, то и атрибуты не нужны. В такие классы необходимо сразу генерить код, который используется для создания батчей.
О-о, как круто. При наличии атрибутов код маппинга пишется влет: просто сериализуем класс стандартной сериализацией и отдаем соответствующей хранимке. Имя хранимки — это +1 атрибут. Всё. Упражнение на час. А генератор рукопашной поддержки ОРМ — намного дольше.

Разрабатываю систему, состоящую из пары-тройки Web Application. Ядра ввиде Web-сервиса, и еще пары Web-сервисов. Долго мучался, и пришел к следующей архитектуре каждого приложения.

1. Data Access Layer
2. Buisness Logic Layer
3. Buisness Entities
4. UI (Web)

Но до сих пор не могу решить, что лучше использовать в качестке Buisness Entities, толи типизированные DataSet, генерируемые студией + генерируемые SqlDataAdapter, толи свои классы, поражденные от DataSet + свои хранимые процедуры.

Собственно инетерсно было бы узнать, как такие приложения разрабатывает народ. Поделитесь опытом плиз.

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

IT>Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.


аналогично, к тому же использование тяжеловесных Датасетов в Веб приложении часто совсем не оправданно.
не смысла грузить Мини базу данных для отображения например списка сотрудников.

у себя я использую примерно следующий вариант:

есть класс Бизнес сущности

public Class User
{
   public string Name{get{...}set{...}}
   //....
}

для него пишется класс БД:

public class CUserDB
{
    public static void Create(CUser p_user);
    public static void CreateRelation(CUser p_user,CRole p_role);
    public static void DeleteRelation(CUser p_user,CRole p_role);
    public static void Delete(CUser p_user);
    public static void Update(CUser p_user);
    public static CUser Load(string p_sUserName);
    public static CUser Load(int p_iUserID);
    public static CUserCollection GetList();
    public static CUserCollection GetList(CRole p_role);
    public static SQLDataReader GetListReader();
    protected static CUser GetObjectFromReader(SqlDataReader p_reader);
}

все операции с базой выполняются через этот класс
классы примитивные и пишутся за 15 минут.

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

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

можно использовать готовый OR-mapping tool.

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

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

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

PZT>можно использовать готовый OR-mapping tool.

А какие готовые OR-mapping tools в природе существуют ?
Дайте ,плиз, линки кто чем пользовался.

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

IT>Самым неправильным решением было использование только датасетов или только бизнес объектов. И то и другое имеет свои достоинства и преимущества, соответственно и применять их нужно там где это целесообразно.

Согласен... как еще один вариант, при использовании Remoting'а очень медленно вычитываются данные с сервера на клиент и обратно....
самый простой выход тут — в таком конкретном случае, для UI пересылать DataTable (например)...

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

Не твоей, а заказчика... если он только поймет, чего ты делаешь И в любом случае, трехзвенка рулит...

IT>Из всего выше сказанного можно сделать следующий вывод — однозначного ответа нет

IT>Я предпочитаю датасетам бизнес объекты, т.к. датасеты хороши либо в совсем примитивных случаях (быстро мышкой накидал), либо в клинически сложных, когда большая часть логики выносится на клиента и он там выпендривается с датасетами как хочет, а сервер потом получает только результат. В остальных 95% случаев бизнес объекты рулят и доставляют наименьшее число хлопот.

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

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

H_D>Согласен... как еще один вариант, при использовании Remoting'а очень медленно вычитываются данные с сервера на клиент и обратно....
H_D>самый простой выход тут — в таком конкретном случае, для UI пересылать DataTable (например)...

DataTable отдельно сам по себе не сериализуется, его можно передать только вместе с датасетом.

H_D>Датасеты себя исчерпывают в тот самый момент, когда надо что-то посложнее списка сотрудников выдать на экран...
H_D>конечно, схемы чуть-чуть улучшают ситуацию, но только чуть

Ну как бы не совсем. Иногда нужно бывает откатить изменения, такая функциональность в датасетах есть. Правда тоже через одно отверстие. Иногда удобно отослать на сервер все изменения, проведённые над датасетом. Но в целом на больших задачах, получается что дешевле с датасетами не связываться.

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

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

H_D>>Согласен... как еще один вариант, при использовании Remoting'а очень медленно вычитываются данные с сервера на клиент и обратно....
H_D>>самый простой выход тут — в таком конкретном случае, для UI пересылать DataTable (например)...

IT>DataTable отдельно сам по себе не сериализуется, его можно передать только вместе с датасетом.
Странно... у меня вот такое свойство:

        public DataTable AllData
        {
            get 
            {
                DataTable retval = new DataTable();
                for (int i = 0; i < CollectionClass.PropertyCount; i++)
                {
                    DataColumn col = new DataColumn(...);
                    retval.Columns.Add(col);
                }
                foreach ( ... )
                {
                    DataRow row = retval.NewRow();
                    try
                    {
                        foreach ( DataColumn col in retval.Columns )
                        {
                            string colName = col.ColumnName;
                            object vle = obj[colName];
                            if ( vle == null )
                                row[colName] = "";
                            else if ( prop.PropertyClass != null )
                                row[colName] = vle.ToString();
                            else
                                row[colName] = vle;
                        }
                    }
                    catch
                    {
                    }
                    retval.Rows.Add(row);
                }
                foreach ( DataColumn col in retval.Columns )
                    col.ExtendedProperties["Property"] = null;
                return retval;            
            }
        }

нормально через Remoting вызывается... причем отрабатывает на сервере, а на клиент тока результат...
DataRow — не сериализуется, факт, а вот DataTable — вполне нормально...

IT>Ну как бы не совсем. Иногда нужно бывает откатить изменения, такая функциональность в датасетах есть. Правда тоже через одно отверстие. Иногда удобно отослать на сервер все изменения, проведённые над датасетом. Но в целом на больших задачах, получается что дешевле с датасетами не связываться.
в моей системе можно только дернуть коллекцию (через вышеприведенное свойство и его аналог, возвращающий DataSet) чтобы получить данные в виде DataSet, а вот все изменения делаются через Remoting и никак иначе... никаких передач DataSet'ов с клиента на сервер... разве что сделать у бизнес объекта свойство типа DataTable/DataSet.
Причина же для появления такого метода чтения данных — remoting очень медленно выполняется, особенно при использовании OwnerData/CustomDraw ListView ( aka TreeGrid2 )...
когда нужно отрисовать 20 объектов по 10 свойств у каждого — это занимает около 30 секунд при дерганьи каждого значения через remoting... а так — за какие-то мгновенья все отрабатывает

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

IT>>DataTable отдельно сам по себе не сериализуется, его можно передать только вместе с датасетом.
H_D>Странно... у меня вот такое свойство:
[skip]
H_D>нормально через Remoting вызывается... причем отрабатывает на сервере, а на клиент тока результат...
H_D>DataRow — не сериализуется, факт, а вот DataTable — вполне нормально...

Значит я не прав

H_D>в моей системе можно только дернуть коллекцию (через вышеприведенное свойство и его аналог, возвращающий DataSet) чтобы получить данные в виде DataSet, а вот все изменения делаются через Remoting и никак иначе... никаких передач DataSet'ов с клиента на сервер... разве что сделать у бизнес объекта свойство типа DataTable/DataSet.

У датасета можно запросить изменения через GetChanges и послать их серверу. Очень быстро и удобно, так что отмахиваться от них не надо.

H_D>Причина же для появления такого метода чтения данных — remoting очень медленно выполняется, особенно при использовании OwnerData/CustomDraw ListView ( aka TreeGrid2 )...
H_D>когда нужно отрисовать 20 объектов по 10 свойств у каждого — это занимает около 30 секунд при дерганьи каждого значения через remoting... а так — за какие-то мгновенья все отрабатывает

Т.е.? Ты за каждым свойством на сервер что-ли ходишь?

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

IT>У датасета можно запросить изменения через GetChanges и послать их серверу. Очень быстро и удобно, так что отмахиваться от них не надо.
Мне оно не нужно, увы.. мне лишнее кэширование не нужно... его в сервере хватает... а так — будет полная #$%%@$%@#%@!... и так мучаюсь... и с содроганием предвкушаю переделку... вернее — доделку под многопользовательский режим... как только транзакция закончилась — надо бы всех оповестить, чтобы данные перечитали... а это — жуткая вешь...
Представь себе — у каждого клиента по 50 Датасетов... а мне надо обновления клиентам разослать... попа, однако....

IT>Т.е.? Ты за каждым свойством на сервер что-ли ходишь?
теперь — нет для того и родил методы, которые DataRow/DataSet возвращают...
щаз вот еще и Кодогенерацию буду писать... но сперва — напишу статью про то, как это вссе устроено... или несколько статей...
а потом — сломаю все нафиг...
Кстати, у тебя немного времени есть? а то я тебе закинул бы того монстрика, которого наваял, чтобы ты его посмотрел

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


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

Из — за их тяжеловесности?

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

_FR>У меня две параллельных модели, причём сущности загружаются из таблицы (то есть датасет первичен), — берём таблицу типизированного датасета и получаем массив сущностей, со своей, немного навороченной (в некоторых местах) обработкой свойств (например, если поле Age должно быть положительным).

Т.е. сначала закачиваешь данные в датасет, а потом переливаешь их в бизнес-объекты?

_FR>Единственное, что здесь надо решить — генерацию кода этих самых сущностей. пока руками (в виду первой беты студии), а потом на R#, например. Процесс совсем не сложный, а плюсы обоих подходов радуют.

Что именно ты собираешься генерировать?

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

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

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

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

IT>>Т.е. сначала закачиваешь данные в датасет, а потом переливаешь их в бизнес-объекты?

_FR>Да. Закачиваю данные в датасет, потом, где надо (наличие логики на клиенте и некоторые расчёты удобнее вести со своими сущностями, хранящими в себе разные результаты вычислений, имеющие особые арифметические операции) получаю сущности из таблицы или другого набора строк. _По месту_, то есть не храню сущности постоянно, это у меня недолгоживущие объекты.

А датасеты хранишь постоянно?

IT>>Что именно ты собираешься генерировать?

_FR>Классы сущностей. Их должно быть несколько десятков, код у них на 60% одинаков (геттеры-сеттеры свойств, закрузка\сохранение) за небольшими исключениями (типы\имена полей). Каждый класс — partial, то есть каждый можно расширить в зависимости от смысла.

Всё это давно умеет RFD.

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

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

Три представления — три раза кодить. Не слишком ли накладно?

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

IT>>>Т.е. сначала закачиваешь данные в датасет, а потом переливаешь их в бизнес-объекты?
_FR>>Да. Закачиваю данные в датасет, потом, где надо (наличие логики на клиенте и некоторые расчёты удобнее вести со своими сущностями, хранящими в себе разные результаты вычислений, имеющие особые арифметические операции) получаю сущности из таблицы или другого набора строк. _По месту_, то есть не храню сущности постоянно, это у меня недолгоживущие объекты.
IT>А датасеты хранишь постоянно?

Да, постоянно. Подгружаю таблицы "по требованию".

IT>>>Что именно ты собираешься генерировать?
_FR>>Классы сущностей. Их должно быть несколько десятков, код у них на 60% одинаков (геттеры-сеттеры свойств, закрузка\сохранение) за небольшими исключениями (типы\имена полей). Каждый класс — partial, то есть каждый можно расширить в зависимости от смысла.
IT>Всё это давно умеет RFD.

Когда, примерно с год назад, я его смотрел, не понравилась идея реализовывать всё через открытые члены класса (сущности через интерфейсы объявлялись), мне же хочется гибкой связи полей БД на поля объекта, которые более естественны, например в базе целочисленная маска, а в объекте — несколько логических флагов, и чтоб о маске "снаружи" никто не догадался. Или представлять целочисленное же поле БД как ТаймСпан в объекте. И ещё было желание на полную использовать второй фрейворк
Сейчас, смотрю, он не только расширился, но и List<T> учится обрабатывать

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

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

Реально-то может всё быть реализовано едино, но иметь возможность работы на три фронта. Начал я делать универсально... накладнее получилось

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

IT>>А датасеты хранишь постоянно?

_FR>Да, постоянно. Подгружаю таблицы "по требованию".

Не нравится мне такая идея. Пару раз примерял к себе, но что-то не пошло.

_FR>Когда, примерно с год назад, я его смотрел, не понравилась идея реализовывать всё через открытые члены класса (сущности через интерфейсы объявлялись),

Такого требования в RFD нет.

_FR> мне же хочется гибкой связи полей БД на поля объекта, которые более естественны, например в базе целочисленная маска, а в объекте — несколько логических флагов, и чтоб о маске "снаружи" никто не догадался.

На энумераторы можно мапить целочисленные константы, можно строковые.

public enum Status
{
    [MapValue("A")] Active,
    [MapValue("I")] Inactive,
    [MapValue("P")] Pending
}

_FR>Или представлять целочисленное же поле БД как ТаймСпан в объекте.

Этого нет. Но добавить это в библиотеку не проблема, тем более что случай не такой уж редкий. Сейчас можно выкрутиться примерно так:

[MapField("Time")]
protected abstract long timeInternal { get; set; }

[MapIgnore]
public TimeSpan Time
{
    get { return timeInternal == 0? TimeSpan.MinValue: new TimeSpan(timeInternal); }
    set { timeInternal = value == TimeSpan.MinValue? 0: value.Ticks;               }
}

_FR>И ещё было желание на полную использовать второй фрейворк
_FR>Сейчас, смотрю, он не только расширился, но и List<T> учится обрабатывать

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

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

IT>>>А датасеты хранишь постоянно?
_FR>>Да, постоянно. Подгружаю таблицы "по требованию".

IT>Не нравится мне такая идея. Пару раз примерял к себе, но что-то не пошло.

Мне тоже, но остановился, по причине того что пользователю придётся одновременно оперировать сразу с несколькими таблицами — тягать из одной в другую, во вьюхах отображать вместо идентификатора парент записи — поле из парент таблицы, при редактировании из комбобокса выбирать связанную запись — всё равно всю таблицу надо грузить Если таблица из сотни записей и их пять — шесть и подгружать каждый раз, то подтормаживать так же будет каждый раз. Второй бонус —

_FR>>Когда, примерно с год назад, я его смотрел, не понравилась идея реализовывать всё через открытые члены класса (сущности через интерфейсы объявлялись),

IT>Такого требования в RFD нет.

То есть можно настроить так, чтобы поля мапились на закрытые\защищённые члены класса? Ага, вижу ниже пример с протектед

_FR>> мне же хочется гибкой связи полей БД на поля объекта, которые более естественны, например в базе целочисленная маска, а в объекте — несколько логических флагов, и чтоб о маске "снаружи" никто не догадался.

IT>На энумераторы можно мапить целочисленные константы, можно строковые.

С енумами ясно, но в базе могут храниться маски, биты которых друг к другу отношения не имеют, например "Просмотрено", "Отредактировано", "Помечено" и более естественным для них, имхо, иметь именно булевские переменные.

_FR>>Или представлять целочисленное же поле БД как ТаймСпан в объекте.
IT>Этого нет. Но добавить это в библиотеку не проблема, тем более что случай не такой уж редкий. Сейчас можно выкрутиться примерно так:

IT>[MapField("Time")]
IT>protected abstract long timeInternal { get; set; }

IT>[MapIgnore]
IT>public TimeSpan Time
IT>{
IT>    get { return timeInternal == 0? TimeSpan.MinValue: new TimeSpan(timeInternal); }
IT>    set { timeInternal = value == TimeSpan.MinValue? 0: value.Ticks;               }
IT>}

Да, примерно это и надо. Нормально ли Rfd отнесётся к тому, что из сеттера "public TimeSpan Time" я брошу исключение. мол "неверное значение"? В смысле получу ли я его (через InnerException конечно) в вызывающей стороне?

_FR>>И ещё было желание на полную использовать второй фрейворк
_FR>>Сейчас, смотрю, он не только расширился, но и List<T> учится обрабатывать

IT>Ага, пытается. Но чтобы использовать на полную нужно переписывать все внутренности. Но тогда прощай совместимость с 1-м фреймворком.

Ну почему же "прощай совместимость". Ради широты охвата можно и продублировать кой-какие куски, зато все будут довольны

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

IT>>Не нравится мне такая идея. Пару раз примерял к себе, но что-то не пошло.

_FR>Мне тоже, но остановился, по причине того что пользователю придётся одновременно оперировать сразу с несколькими таблицами — тягать из одной в другую, во вьюхах отображать вместо идентификатора парент записи — поле из парент таблицы, при редактировании из комбобокса выбирать связанную запись — всё равно всю таблицу надо грузить Если таблица из сотни записей и их пять — шесть и подгружать каждый раз, то подтормаживать так же будет каждый раз. Второй бонус —

Значит продолжим, отвлёкся я

Второй бонус в возможности отмены\возврата операций над иерархией записей — хоть всё дерево пользовательнигде и не видит, но оно у меня есть и при необходимости я могу что-то пересчитать, что-то удалить, что-то вернуть. Опять же, имея всё это сразу, получается быстрее, чем запрашивать каждый раз.

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

_FR>То есть можно настроить так, чтобы поля мапились на закрытые\защищённые члены класса? Ага, вижу ниже пример с протектед

Это поддерживается только для абстрактных классов.

IT>>На энумераторы можно мапить целочисленные константы, можно строковые.

_FR>С енумами ясно, но в базе могут храниться маски, биты которых друг к другу отношения не имеют, например "Просмотрено", "Отредактировано", "Помечено" и более естественным для них, имхо, иметь именно булевские переменные.

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

_FR>Да, примерно это и надо. Нормально ли Rfd отнесётся к тому, что из сеттера "public TimeSpan Time" я брошу исключение. мол "неверное значение"? В смысле получу ли я его (через InnerException конечно) в вызывающей стороне?

Нормально.

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

IT>- отсутвие поддержки перечислителей, соответственно абстракция от структуры данных тоже идёт лесом. Использование захаркоженных значений расползается по системе, в результате чего их потом приходится ловить и давить как тараканов.
Что такое перечислители и захаркоженные значения? Как я понял, захаркоженные значения — это что-то типа

TableX.Fields["Age"].GetValue();

А есть способы избежать этого? Эти самые загадочные перечислители?

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


PS
В проектировании я вообще-то чайник, но кошмар с табличками/датасетами уже достал. Присматриваюсь к бизнес-объектам, но пугает большой (ИМХО) объём рутинной работы.

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

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

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

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

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

Думаю что для этого даже недели не понадобится. Особенно на 2-м фреймворке. На работе у меня его нет, приеду домой попробую изобразить кое что.

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

IT>Думаю что для этого даже недели не понадобится. Особенно на 2-м фреймворке. На работе у меня его нет, приеду домой попробую изобразить кое что.
Сортировка, в принципе легко. А вот фильтрация — уже значительно сложней. Учитывая что там есть язык описания фильтров. Для 2.0 конечно можно пришпандорить Predicate<T>. Правда — это не полностью аналогичное решение. Фильтры с языком все таки более независимы от хранимых данных в коллекции. Ну и насколько я помню (сам уже давно с такими структурами не работал), там есть некоторый аналог индексирования.

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

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

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

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

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

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

IT>Думаю что для этого даже недели не понадобится. Особенно на 2-м фреймворке. На работе у меня его нет, приеду домой попробую изобразить кое что.

10 минут на тощак.

ObjectView:

public delegate bool TestObject<T>(T obj);

public class ObjectView
{
    public static List<T> Filter<T>(List<T> list, TestObject<T> test)
    {
        List<T> result = new List<T>();

        foreach (T t in list)
            if (test(t))
                result.Add(t);

        return result;
    }

    public static List<T> Filter<T>(List<T> list, TestObject<T> test, Comparison<T> cmp)
    {
        List<T> result = new List<T>();

        foreach (T t in list)
            if (test(t))
                result.Add(t);

        result.Sort(cmp);

        return result;
    }
}

Пример использования:

public class Class1
{
    public class TestObject
    {
        public int A;
        public int B;
    }

    public void Exampe(List<TestObject> list)
    {
        List<TestObject> view = ObjectView.Filter(
            list,
            delegate(TestObject t)
            {
                return t.A < t.B;
            });

        List<TestObject> sortedView = ObjectView.Filter(
            list,
            delegate(TestObject t)
            {
                return t.A < t.B;
            },
            delegate(TestObject x, TestObject y)
            {
                return x.A - y.A;
            });
    }
}

И что самое интересное — всё type safety.

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

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

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

IT>>Думаю что для этого даже недели не понадобится. Особенно на 2-м фреймворке. На работе у меня его нет, приеду домой попробую изобразить кое что.

IT>10 минут на тощак.

10 секунд сходу

Predicate<MyClass> MyPredicate = delegate(MyClass isEqual10)
{
    return (isEqual10.Field==10)?true:false;
}
result=List<MyClass>.FindAll(myList, MyPredicate);

Двойки под рукой нет, поэтому может быть что-то неправильно.
Но тут есть еще вопрос, который меня волнует. Условие фильтрации часто (у меня например) определяется динамически. И в этом случае — язык значительно удобней.
С уважением, Gleb.

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

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

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

Дождусь дисков, посмотрю...

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

IT>public class Class1
IT>{
IT>  public class TestObject
IT>  {
IT>    public int A;
IT>    public int B;
IT>  }

IT>  public void Exampe(List<TestObject> list)
IT>  {
       List<TestObject> view = list.FindAll(delegate(TestObject t) {
            return t.A < t.B;
       });

       List<TestObject> sortedView = list.FindAll(delegate(TestObject t) {
         return t.A < t.B;
       });
       sortedView.Sort(delegate(TestObject x, TestObject y) {
         return x.A - y.A;
       });
IT>  }
IT>}

Я бы и готовым обошёлся

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

_FR>Я бы и готовым обошёлся

Э нет. Речь шла о сложности имплементации

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

GZ>10 секунд сходу

Можно и так. А ты говоришь неделю

GZ>Но тут есть еще вопрос, который меня волнует. Условие фильтрации часто (у меня например) определяется динамически. И в этом случае — язык значительно удобней.

А ты попробуй сравни. Напиши два варианта и посмотри. Но в любом случае, твой аргумент про отсутствие функциональности как в DataView вычёркиваем.

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

GZ>>10 секунд сходу

IT>Можно и так. А ты говоришь неделю
Ну я не подразумевал 2.0. До ноября еще дожить нужно. И еще чтобы при этом деньги были для Microsoft.

GZ>>Но тут есть еще вопрос, который меня волнует. Условие фильтрации часто (у меня например) определяется динамически. И в этом случае — язык значительно удобней.
IT>А ты попробуй сравни. Напиши два варианта и посмотри. Но в любом случае, твой аргумент про отсутствие функциональности как в DataView вычёркиваем.
Ок. Частая задача. Пользователю выводится грид. У пользователя есть некоторый набор контролов управления с помощью которого он может его фильтровать и сортировать. В результате, поскольку у нас Predicate<T> привязан к типу, то придется делать для каждого типа объекта свой фильтр. Для DataView все обойдет сбором строки фильтрации.

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

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

_FR>>Я бы и готовым обошёлся
IT>Э нет. Речь шла о сложности имплементации

Ну я и подтвердил, что сложности и нету
Единственная трабла — дизайнеры плохо с обобщёнными (generic) типами работают

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

IT>А датасеты хранишь постоянно?
IT>>>Что именно ты собираешься генерировать?
_FR>>Классы сущностей. Их должно быть несколько десятков, код у них на 60% одинаков (геттеры-сеттеры свойств, закрузка\сохранение) за небольшими исключениями (типы\имена полей). Каждый класс — partial, то есть каждый можно расширить в зависимости от смысла.
IT>Всё это давно умеет RFD.

Я понял! Я хочу генерить описание классов, которые затем буду передовать RFD. А что? Схема есть, по ней появляются описания абстрактных классов со всеми необходимыми аттрибутами, а RFD загоняет мне в них данные. Вот дождусь студии, буду скрещивать

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

IT>>Можно и так. А ты говоришь неделю
GZ>Ну я не подразумевал 2.0. До ноября еще дожить нужно. И еще чтобы при этом деньги были для Microsoft.

На 1.1 тоже самое, только выглядит чуть более громоздко.

GZ>Ок. Частая задача. Пользователю выводится грид. У пользователя есть некоторый набор контролов управления с помощью которого он может его фильтровать и сортировать. В результате, поскольку у нас Predicate<T> привязан к типу, то придется делать для каждого типа объекта свой фильтр. Для DataView все обойдет сбором строки фильтрации.

А сколько записей всреднем в гриде?

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

_FR>Я понял! Я хочу генерить описание классов, которые затем буду передовать RFD. А что? Схема есть, по ней появляются описания абстрактных классов со всеми необходимыми аттрибутами, а RFD загоняет мне в них данные.

А схема на чём?

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

GZ>>Ок. Частая задача. Пользователю выводится грид. У пользователя есть некоторый набор контролов управления с помощью которого он может его фильтровать и сортировать. В результате, поскольку у нас Predicate<T> привязан к типу, то придется делать для каждого типа объекта свой фильтр. Для DataView все обойдет сбором строки фильтрации.

IT>А сколько записей всреднем в гриде?
Да хоть 10, функциональность в требованиях есть, значит вынь да положь. Кол-во записей — это совершенно другая проблема.

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

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

GZ>>>Ок. Частая задача. Пользователю выводится грид. У пользователя есть некоторый набор контролов управления с помощью которого он может его фильтровать и сортировать. В результате, поскольку у нас Predicate<T> привязан к типу, то придется делать для каждого типа объекта свой фильтр. Для DataView все обойдет сбором строки фильтрации.

IT>>А сколько записей всреднем в гриде?
GZ>Да хоть 10, функциональность в требованиях есть, значит вынь да положь. Кол-во записей — это совершенно другая проблема.

Падажди... Сколько максимум записей? И сколько критериев?

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

_FR>>Я понял! Я хочу генерить описание классов, которые затем буду передовать RFD. А что? Схема есть, по ней появляются описания абстрактных классов со всеми необходимыми аттрибутами, а RFD загоняет мне в них данные.

IT>А схема на чём?

Если полностью отказаться от DataSet'ов, то в своём формате (хотя руками и его править неинтересно ), иначе добавить в проект датасет, поменять в нём Custom Tool на прогу, использующую R# и поменять Build Action на Embedded Resource или None.

Генератор должен будет проставлять много аттрибутов для красивой работы с объектами в Design-Time + сделать дизайнер для DataSource и DataMember, обращающийся к RFD.

Получится уже и presentatin layer framework

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

_FR>>Если полностью отказаться от DataSet'ов, то в своём формате (хотя руками и его править неинтересно ), иначе добавить в проект датасет, поменять в нём Custom Tool на прогу, использующую R# и поменять Build Action на Embedded Resource или None.
IT>Т.е. в своей схеме ты собираешься описывать структуру класса, а потом генерировать класс?
IT>1. Чем это принципиально отличается от датасетов? Например, как ты собираешься имплементировать вычисляемые поля типа FullName, если есть FirstName и LastName?

Разобрать. Там всё просто — в крадратных кавыках имена свойств — надо их вызвать. Набор функций предельно ограничен, ничего сложного вроде нету.

IT>2. Написание абстрактного класса ничем не длиннее. а может быть даже короче и быстрее написания схемы.

Не "написания", а рисования

IT>Т.е. в чём поинт иметь схему в этом случае. Она ничего не упрощает, только усложняет.

Для получения в рантайме и дизайнтайме готовых глассов для работы с базой данных не придётся писать ни одной строчки — то есть во время разработки имеем все плюсы автоматизированного дизайнера, а во время выполнения избавляемся от грамоздкости ДатаСета. Хочется такого.

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

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

_FR>Дождусь дисков, посмотрю...

Если будет не сложно, когда посмотрите сделайете пост пожалуйста.

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

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

GZ>>>>Ок. Частая задача. Пользователю выводится грид. У пользователя есть некоторый набор контролов управления с помощью которого он может его фильтровать и сортировать. В результате, поскольку у нас Predicate<T> привязан к типу, то придется делать для каждого типа объекта свой фильтр. Для DataView все обойдет сбором строки фильтрации.

IT>>>А сколько записей всреднем в гриде?
GZ>>Да хоть 10, функциональность в требованиях есть, значит вынь да положь. Кол-во записей — это совершенно другая проблема.

IT>Падажди... Сколько максимум записей? И сколько критериев?
Критерии = > >= < <= != для строк добавляются like '%xxx' like '%xxx%' like 'xxx%' и те же самые но not like.
Полей в среднем штук 10.
Записей наверное в среднем в районе 1000. Максимума как такового нет, просто по бизнес задаче примерно так получается.

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

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

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

_FR>>Дождусь дисков, посмотрю...

G2>Если будет не сложно, когда посмотрите сделайете пост пожалуйста.

Договорились

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

IT>>Падажди... Сколько максимум записей? И сколько критериев?
GZ>Критерии = > >= < <= != для строк добавляются like '%xxx' like '%xxx%' like 'xxx%' и те же самые но not like.
GZ>Полей в среднем штук 10.

Т.е. все возможные комбинации?

GZ>Записей наверное в среднем в районе 1000. Максимума как такового нет, просто по бизнес задаче примерно так получается.

А запросе это всё сделать нельзя?

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

_FR>Разобрать. Там всё просто — в крадратных кавыках имена свойств — надо их вызвать. Набор функций предельно ограничен, ничего сложного вроде нету.

Когда появится дай знать

IT>>2. Написание абстрактного класса ничем не длиннее. а может быть даже короче и быстрее написания схемы.

_FR>Не "написания", а рисования

Ты и имена полей рисуешь? Или всё же ручками набиваешь?

IT>>Т.е. в чём поинт иметь схему в этом случае. Она ничего не упрощает, только усложняет.

_FR>Для получения в рантайме и дизайнтайме готовых глассов для работы с базой данных не придётся писать ни одной строчки — то есть во время разработки имеем все плюсы автоматизированного дизайнера, а во время выполнения избавляемся от грамоздкости ДатаСета. Хочется такого.

Это изобретение своего велосипеда. Ты не получишь всех возможностей бизнес-объектов и лишишься фич датасета.

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

IT>>>2. Написание абстрактного класса ничем не длиннее. а может быть даже короче и быстрее написания схемы.
_FR>>Не "написания", а рисования
IT>Ты и имена полей рисуешь? Или всё же ручками набиваешь?

Здесь да, здесь я не прав. Имена полей набиваю.

IT>>>Т.е. в чём поинт иметь схему в этом случае. Она ничего не упрощает, только усложняет.

_FR>>Для получения в рантайме и дизайнтайме готовых глассов для работы с базой данных не придётся писать ни одной строчки — то есть во время разработки имеем все плюсы автоматизированного дизайнера, а во время выполнения избавляемся от грамоздкости ДатаСета. Хочется такого.
IT>Это изобретение своего велосипеда. Ты не получишь всех возможностей бизнес-объектов и лишишься фич датасета.

Какие возможности бизнес-объектов, которые предоставляет RFD, я могу потерять?

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

_FR>>Какие возможности бизнес-объектов, которые предоставляет RFD, я могу потерять?

IT>RFD тут не при чём. Потерять ты можешь инкапсуляцию, т.к. сгенерированные классы расширять ты не сможешь.



IT>И даже в C# 2.0 partial классы в данном случае будут выглядеть как затычка.



IT>Я вообще не понимаю зачем что-то генерить из чего-то, если сам результат по определению можно набить руками быстрее чем нарисовать источник для генерации. Вот скажи мне что быстрее, нарисовать схему и сгенерировать класс или написать:

IT>public abstract class Person
IT>{
IT>    public abstract string FirstName { get; set; }
IT>    public abstract string LastName  { get; set; }
IT>}

Сдаюсь! Набрать быстрее . Но, может, болезнь у меня такая но пора бы уже, имея такой инструмент, как .NET, набирать меньше. Работу со схемой и объяснить проще\нагляднее, и на схему можно "перетащить" таблицу из "Server Explorer" (и несколько таблиц пачкой, вместе со связями), и... ну, я считаю эстетичнее

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


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

GZ>>Записей наверное в среднем в районе 1000. Максимума как такового нет, просто по бизнес задаче примерно так получается.

IT>А запросе это всё сделать нельзя?
Можно, старая версия так и делала. Только у базы плохо с масштабируемостью было. Сейчас как-бы делается на клиенте.

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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;

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

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

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

Таблица Examinations не может содержать поля типа NULL, а также одна запись в таблице Patients c PatientID должен будет говорить о наличие только одной записи в Examinations c ExamID.

Подробнее структура таблицы здесь

Автор: G2
Дата: 14.06.05

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

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

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

IT>

IT>SELECT @PatientID
IT>

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

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

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

Подсмотрел в "Designing Data Tier Components and Passind Data Through Tier".
Глава "How to Represent Collections and Hierarchies of Data in a Business Entity".

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

G2>Таблица Examinations не может содержать поля типа NULL, а также одна запись в таблице Patients c PatientID должен будет говорить о наличие только одной записи в Examinations c ExamID.

Т.е. у тебя связь один-к-одному/

IT>>1. Сделать два спрока. Один для добавления мастер-записи, второй для добавления дочерних.
G2>Уже так сделано, если я правильно понял замечание.

С той лишь разницей, что вызывать спроки и контролировать транзакцию будет BL. Но если у тебя связь 1-1, то можно вообще всё сделать в одной процедуре.

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

Что значит "уже существует"? Вообще я здесь меню ввиду output параметр vs. select.

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

G2>Подсмотрел в "Designing Data Tier Components and Passind Data Through Tier".
G2>Глава "How to Represent Collections and Hierarchies of Data in a Business Entity".

И что там рекомендуется использовать для каждого объекта DataSet для хранения его дочерних объектов?

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

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

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

Да, сори, американизмы, блин. Stored Procedure -> Stored Proc -> sproc -> спрок

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

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

Roundtrip. В данном контексте похождение на севрер и обратно. Опять же... сори

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

И как ты их потом используешь?

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

IT>Stored Procedure -> Stored Proc -> sproc -> спрок
IT>Roundtrip. В данном контексте похождение на севрер и обратно. Опять же... сори

Ничего, мне спросить не лень, а узнать не страшно Спасибо. Это интересно.

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

IT>И как ты их потом используешь?

return  0 -- всё в порядке. все SELECT-процедуры имеют только один такой return без вариантов
return -1 -- Не хватило прав для выполнения изменений.
-- Далее, так как есть System.Data.SqlClient.SqlConnection.FireInfoMessageEventOnUserErrors,
-- сразу после raiserror(N'Message', 16, 1)
return -2 -- При логине неверный пароль
return -3 -- Невозможность изменения записи с точки зрения SQL-серверной логики

Клиент имеет доступ к данным только через процедуры, их вид (сигнатуры) унифицированны, исполняются через одну "дырку". На клиенте проблематично узнать не в строковом виде причину ошибки (кроме строкового параметра raiseerror, а что-то более-менее понятное юзеру сообщить охота.
В основном, из-за этого.

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

_FR>>Клиент имеет доступ к данным только через процедуры, их вид (сигнатуры) унифицированны, исполняются через одну "дырку". На клиенте проблематично узнать не в строковом виде причину ошибки (кроме строкового параметра raiseerror, а что-то более-менее понятное юзеру сообщить охота.
_FR>>В основном, из-за этого.

IT>Понятно. У тебя навороченная серверная логика. Я стараюсь всячески избегать такого подходя.

Мы тоже как можем стараемся! Но ссылочная целосность + сложность на клиенте провести какие-то операции над _множеством_ данных... Кое-что, да, каюсь, проверяется и в СУБД

Мы решили, что логикой хранения\целостности данных будет заниматься сервер, а бизнес-логику всю считаем на клиенте. Кесарю-кесарево. Сервер плохо предназначен для расчётов, а известные мне системы представления данных на клиенте — для соблюдения ссылочной целостности в распределённой системе. Трёхзвенка дело конечно хорошее, но хотелось бы уберечься и от "ручной" правки строк в БД.

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

IT>>Понятно. У тебя навороченная серверная логика. Я стараюсь всячески избегать такого подходя.

_FR>Мы тоже как можем стараемся!

Ну да, я вижу. С логикой в БД обычно такая ситуация — либо она есть, либо её нет. Это как нельзя быть немножко беременной, либо да, либо нет. Так и тут.

_FR>Но ссылочная целосность + сложность на клиенте провести какие-то операции над _множеством_ данных... Кое-что, да, каюсь, проверяется и в СУБД

Сылочная целостность, да и вообще вся data integrity делается с помощью FK и constraints. Обычно этого более чем достаточно. Зачем заниматься велосипедным спортом?

_FR>Мы решили, что логикой хранения\целостности данных будет заниматься сервер, а бизнес-логику всю считаем на клиенте. Кесарю-кесарево. Сервер плохо предназначен для расчётов, а известные мне системы представления данных на клиенте — для соблюдения ссылочной целостности в распределённой системе. Трёхзвенка дело конечно хорошее, но хотелось бы уберечься и от "ручной" правки строк в БД.

Что значит уберечься? Если к серверу БД имеют доступ только сервера приложений, то враг мимо не пройдёт. Это вообще примитивная задача для админа.

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

_FR>>Но ссылочная целосность + сложность на клиенте провести какие-то операции над _множеством_ данных... Кое-что, да, каюсь, проверяется и в СУБД

IT>Сылочная целостность, да и вообще вся data integrity делается с помощью FK и constraints. Обычно этого более чем достаточно. Зачем заниматься велосипедным спортом?

Даже без тригеров?

Приходится Нужна возможность чего-то наподобии репликации (DTS не устраивает, так как пользователи не имеют навыков по поддержанию всего этого хозяйства), когда данные грузятся пачкамии констрэинты с тригерами надо бы отключить. Из-за этого от тригеров и прочих удобных средств пришлось отказаться.

_FR>>Мы решили, что логикой хранения\целостности данных будет заниматься сервер, а бизнес-логику всю считаем на клиенте. Кесарю-кесарево. Сервер плохо предназначен для расчётов, а известные мне системы представления данных на клиенте — для соблюдения ссылочной целостности в распределённой системе. Трёхзвенка дело конечно хорошее, но хотелось бы уберечься и от "ручной" правки строк в БД.

IT>Что значит уберечься? Если к серверу БД имеют доступ только сервера приложений, то враг мимо не пройдёт. Это вообще примитивная задача для админа.

В идеале к таблицам доступа не должно быть. Если админ толковый, то пожалуйста, а если считает себя "хакером", то пока определится с тем, как себе прав назначить, уже толковым станет и бросит ерундой заниматься. Любят некоторые на таблички "поглазеть" а потом к нам притензии, мол "из базы данных записи пропадают"

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

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

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

Справедливости ради, стоит отметить, что (как минимум для MS SQL) можно обойтись без раундтрипов. Формируем примерно такой батч:

begin tran
declare @masterID int
exec sp_add_master @param1, @param2, ..., @masterID output

exec sp_add_detail @masterID, @param3, @param4, ...
exec sp_add_detail @masterID, @param5, @param6, ...
...
commit tran

Формировать такой батч несколько сложнее, чем XML, но зато упрощается серверная сторона.

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

S>Справедливости ради, стоит отметить, что (как минимум для MS SQL) можно обойтись без раундтрипов. Формируем примерно такой батч:

S>begin tran
S>declare @masterID int
S>exec sp_add_master @param1, @param2, ..., @masterID output

S>exec sp_add_detail @masterID, @param3, @param4, ...
S>exec sp_add_detail @masterID, @param5, @param6, ...
S>...
S>commit tran

"Разименовывая" "@masterID, @param3" ??

Здравствуйте, _FRED_, Вы писали:
_FR>"Разименовывая" "@masterID, @param3" ??
Чо?

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

_FR>>"Разименовывая" "@masterID, @param3" ??
S>Чо?

S>begin tran
S>declare @masterID int
S>exec sp_add_master @param1, @param2, ..., @masterID output

S>exec sp_add_detail @masterID, @param3, @param4, ...
S>exec sp_add_detail @masterID, @param5, @param6, ...
S>...
S>commit tran

Это CommandText одной SqlCommand со множеством параметров?

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


_FR>Это CommandText одной SqlCommand со множеством параметров?
Ага. @masterID — это не параметр.

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

_FR>>Это CommandText одной SqlCommand со множеством параметров?
S>Ага. @masterID — это не параметр.

Угу, спасиба. Остаётся придумать, как такое динамически строить

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

IT>Если и сложнее, то не намного.
А если учесть, что частенько объект достаточно просто сериализовать, то xml получается проще...
Но на сервере с ним надо будет повозиться.

Здравствуйте, IT, Вы писали:
IT>Какое извращение
Я бы постеснялся называть способ, приводящий для типичных мастер/деталь к 10кратному росту производительности по сравнению с одиночными запросами и к 10кратному снижению потребляемой серверным процессом памяти по сравнению с парсингом XML извращением
IT>Если и сложнее, то не намного.
В принципе да. Слабо изобрести интерфейс StatementBatch с поддержкой зависимостей между стейтментами? Чтобы все не хуже, чем в обычных SqlCommand. Я вот так сходу чтой-то стесняюсь.

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

S> к 10кратному снижению потребляемой серверным процессом памяти по сравнению с парсингом XML извращением
Да ладно к 10 кратному... Не больше пяти..
А если серьезно, то в нормальных условиях это мелочи, плюс-минус 10кб роли не играют...

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

IT>Так никто и не спорит. Но для того чтобы попасть из разряда извращений в копилку разработчика нужно всё это доказать. Вон Merle уже говорит, что не в 10, а всего лишь в 5
IT>А вообще надо будет нашего DB архитектора попытать на эту тему. Чувак из MS и во всю двигает XML подход, интересно что он на это скажет
Расскажи потом — а то самому интересно.
IT>>>Если и сложнее, то не намного.
S>>В принципе да. Слабо изобрести интерфейс StatementBatch с поддержкой зависимостей между стейтментами? Чтобы все не хуже, чем в обычных SqlCommand. Я вот так сходу чтой-то стесняюсь.

IT>Какой ещё интерфейс? Тут надо просто пару хелперов нарисовать.
Может быть. Настораживает изобилие параметров. Ну вот там, для вставки ордера в "обычном" режиме мы
— вызываем SqlCommand для order, дав ему все параметры, и получаем ID order
— готовим SqlCommand для order_item и в цикле:
-- даем ему очередную пачку параметров (@OrderID, @productId, @quantity) и выполняем.
Что хорошо, так это постоянство имен параметров для order_item. "Второе измерение" им выдается при помощи цикла.
А тут нам придется в цикле вместо Execute делать что-то другое, типа "накопить". При этом параметры могут биндиться как на предоставленные константы (@productId, @quantity), так и на результаты предыдущего запроса (@OrderId).

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

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

IT>>Если и сложнее, то не намного.
M>А если учесть, что частенько объект достаточно просто сериализовать, то xml получается проще...

Просто вряд ли получится. Придется dml псевдо-команды в xml'ном виде вводить.

M>Но на сервере с ним надо будет повозиться.

Ага.
А по сути перенести весь алгоритм формирования батча, о котором упоминал Sinclair, из C# (Delphi и т.п.) в TSQL.

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

kig>Просто вряд ли получится. Придется dml псевдо-команды в xml'ном виде вводить.
Зачем???!

kig>А по сути перенести весь алгоритм формирования батча, о котором упоминал Sinclair, из C# (Delphi и т.п.) в TSQL.
Да, только выполнять его придется наиболее естественным для T-SQL образом, тоесть реляционными запросами, что приятно.

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

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

kig>>Просто вряд ли получится. Придется dml псевдо-команды в xml'ном виде вводить.
M>Зачем???!
Ну засериализовал ты объект. И как понять, чего ты с ним будешь делать на серверной стороне? Добавлять, удалять, апдейтить и т.д.?


kig>>А по сути перенести весь алгоритм формирования батча, о котором упоминал Sinclair, из C# (Delphi и т.п.) в TSQL.
M>Да, только выполнять его придется наиболее естественным для T-SQL образом, тоесть реляционными запросами, что приятно.
Сразу вопросик — а разве батч, приехавший на сервер, состоит не из реляционных запросов?
Поясни "выполнять его придется наиболее естественным для T-SQL образом". Парсинг/преобразование через MSXML в реляционный код — это естественный путь для T-SQL?

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

kig>Ну засериализовал ты объект. И как понять, чего ты с ним будешь делать на серверной стороне? Добавлять, удалять, апдейтить и т.д.?
Ну так яж его конкретной процедуре на сервере передаю, она и знает что с этим xml-ем делать.

kig>Сразу вопросик — а разве батч, приехавший на сервер, состоит не из реляционных запросов?
В этом случае проблемы с формированием его на клиенте, от которых мы пытаемся уйти формируя xml легким движением руки.

kig>Поясни "выполнять его придется наиболее естественным для T-SQL образом". Парсинг/преобразование через MSXML в реляционный код — это естественный путь для T-SQL?
Это делается прозрачно для разработчика, одним запросом, и на выходе получается реляционная таблица данные из которой рспихиваются куда надо.

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

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

kig>>Ну засериализовал ты объект. И как понять, чего ты с ним будешь делать на серверной стороне? Добавлять, удалять, апдейтить и т.д.?
M>Ну так яж его конкретной процедуре на сервере передаю, она и знает что с этим xml-ем делать.

Итого: каждый класс объектов * действия с такими объектами = кол-во серверных СП для этого класса. Где, в отличии от классики, имеем один параметр text/ntext, принимающий сериализованный в xml объект этого класса. А внутри таких СП преобразуем xml в реляционный код. И в чем выгрыш такого подхода? По сравнению с классическим подходом. Тем, что входной параметр один? И все?

Вот мои минусы такого подхода:
1. Кол-во СП == классическому — выгрыша никакого.
2. Возвращаемые параметры? По логике, надо тоже в xml возвращать, а то "протокол" какой-то несимметричный получается.
3. Полная потеря "типизации" => контроль входного xml на предмет ошибок => аналогия: представь себе C# код, где у методов один параметр string. С xml внутри.


kig>>Сразу вопросик — а разве батч, приехавший на сервер, состоит не из реляционных запросов?
M>В этом случае проблемы с формированием его на клиенте, от которых мы пытаемся уйти формируя xml легким движением руки.

И тем же легким движением руки создавая головную боль разработчикам таких СП, в плане манипулирования с xml. Особенно при массовом рефакторинге. А соотвественно и тестерам. Которые будут ловить несоответствия в рантайме.
Хотя надыбать/написать тулзу, которая по классическим СП генерит методы в код C#, проблем нет.

kig>>Поясни "выполнять его придется наиболее естественным для T-SQL образом". Парсинг/преобразование через MSXML в реляционный код — это естественный путь для T-SQL?
M>Это делается прозрачно для разработчика, одним запросом, и на выходе получается реляционная таблица данные из которой рспихиваются куда надо.
Я смотрю, ты T-SQL писателей за разработчиков не держишь.

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

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

G2>>Таблица Examinations не может содержать поля типа NULL, а также одна запись в таблице Patients c PatientID должен будет говорить о наличие только одной записи в Examinations c ExamID.

IT>Т.е. у тебя связь один-к-одному/

Если точнее, должен также участвововать параметр @StartTimeStamp, т.е. я хочу, чтобы на конкретную StartTimeStamp была одна запись в таблице Patients c PatientID и одной записью в Examinations c ExamID. Для другого @StartTimeStamp, изменился только ExamID.

IT>С той лишь разницей, что вызывать спроки и контролировать транзакцию будет BL. Но если у тебя связь 1-1, то можно вообще всё сделать в одной процедуре.
Т.е 2 insert'a в 2 таблицах в одной процедуре?

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

IT>Что значит "уже существует"? Вообще я здесь меню ввиду output параметр vs. select.
Пример, если можно, пожалуйста, для меня тяжело понимать на словах.

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

G2>>Подсмотрел в "Designing Data Tier Components and Passind Data Through Tier".
G2>>Глава "How to Represent Collections and Hierarchies of Data in a Business Entity".

IT>И что там рекомендуется использовать для каждого объекта DataSet для хранения его дочерних объектов?
Вот именно, в простом примере, такой как у меня сложности используется DataSet, поэтому, не найдя комментариев, почему так, решил делать, как умные дядьки делают.

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

kig>Итого: каждый класс объектов * действия с такими объектами = кол-во серверных СП для этого класса.
В общем случае нет.

kig> И в чем выгрыш такого подхода? По сравнению с классическим подходом. Тем, что входной параметр один? И все?
Нет. В легкости подготовки объекта к сохранению, в относительной легкости разбора, в отсутствии накладных расходов при сохранении сложного объекта.

kig>1. Кол-во СП == классическому — выгрыша никакого.
Это не минус, это просто отсутствие плюсов да и то в самом худшем случае.

kig>2. Возвращаемые параметры? По логике, надо тоже в xml возвращать, а то "протокол" какой-то несимметричный получается.
По логике, параметры должны возвращаться в реляционном рекордсете и никакой несимметричности тут нет.

kig>3. Полная потеря "типизации" => контроль входного xml на предмет ошибок =>
Никакой потери, все проверки можно сделать после преобразования xml-я в реляционную таблицу.

kig> аналогия: представь себе C# код, где у методов один параметр string. С xml внутри.
Ну ты же не в ручную это будешь разбирать, сделаешь deserialize и все косяки тут же вылезут, так и здесь. Так что не работает аналогия..


kig>И тем же легким движением руки создавая головную боль разработчикам таких СП, в плане манипулирования с xml.
Да нет этой головной боли, один раз OPENXML вызвать — проблема что ли? Вся фишка в том, что даже сейчас преобразование xml-я в реляционную таблицу на сервере делается стажером за 10 минут, я проверял.

kig> Особенно при массовом рефакторинге. А соотвественно и тестерам. Которые будут ловить несоответствия в рантайме.
А в классическом варианте при рефакторинге все гладко проходит? Нет конечно, та же фигня, только в профиль. Это проблема передачи данных между разными средами с разными формтами и решается она только ручным контролем на принимающей и передающей стороне. И xml, в данном случае, помогает хотя бы отчасти это дело автоматизировать, пускай и чуть большей затратой ресурсов на парсинг параметров. Но в большинстве случаев, если не брать в рассчет самые примитивные, это вполне приемлимая цена.

kig>Я смотрю, ты T-SQL писателей за разработчиков не держишь.
Еще как держу, пусть делом занимаются, а не параметры в табличку перекладывают...

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

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

kig>>Итого: каждый класс объектов * действия с такими объектами = кол-во серверных СП для этого класса.
M>В общем случае нет.

Т.е. СП для работы с композитными объектами (в реляции — мастер-детейл). Правильно понял?

kig>> И в чем выгрыш такого подхода? По сравнению с классическим подходом. Тем, что входной параметр один? И все?
M>Нет. В легкости подготовки объекта к сохранению, в относительной легкости разбора, в отсутствии накладных расходов при сохранении сложного объекта.

kig>>1. Кол-во СП == классическому — выгрыша никакого.
M>Это не минус, это просто отсутствие плюсов да и то в самом худшем случае.

kig>>2. Возвращаемые параметры? По логике, надо тоже в xml возвращать, а то "протокол" какой-то несимметричный получается.
M>По логике, параметры должны возвращаться в реляционном рекордсете и никакой несимметричности тут нет.

kig>>3. Полная потеря "типизации" => контроль входного xml на предмет ошибок =>
M>Никакой потери, все проверки можно сделать после преобразования xml-я в реляционную таблицу.

Т.е. все-таки делать? Блин... опять рантайм.

kig>> аналогия: представь себе C# код, где у методов один параметр string. С xml внутри.
M>Ну ты же не в ручную это будешь разбирать, сделаешь deserialize и все косяки тут же вылезут, так и здесь. Так что не работает аналогия..

Работает. Int'у ты string не присвоишь. Тебя компилятор пошлет (о слаботипизированных языках не говорим). "сделаешь deserialize и все косяки тут же вылезут" — это в рантайме. А это лишние затраты на тестирование. Хотя бы быть уверенным, что ты все ветки покрыл. А так это компилятор на себя берет. Почувствуй разницу.


kig>>И тем же легким движением руки создавая головную боль разработчикам таких СП, в плане манипулирования с xml.
M>Да нет этой головной боли, один раз OPENXML вызвать — проблема что ли? Вся фишка в том, что даже сейчас преобразование xml-я в реляционную таблицу на сервере делается стажером за 10 минут, я проверял.


kig>> Особенно при массовом рефакторинге. А соотвественно и тестерам. Которые будут ловить несоответствия в рантайме.
M>А в классическом варианте при рефакторинге все гладко проходит? Нет конечно, та же фигня, только в профиль. Это проблема передачи данных между разными средами с разными формтами и решается она только ручным контролем на принимающей и передающей стороне. И xml, в данном случае, помогает хотя бы отчасти это дело автоматизировать, пускай и чуть большей затратой ресурсов на парсинг параметров. Но в большинстве случаев, если не брать в рассчет самые примитивные, это вполне приемлимая цена.

Между средами можно по разному передавать. Можно, как предлагаешь ты. Вводя промежуточный слой в виде xml. Но в этом случае ты
откладываешь разбор полетов (ошибки) до момента запуска прилолжения. И появляется у тебя ручной контроль на сторонах. Например, на сложных объектах, если у тебя изменилось 1-ко-многим на многие-ко-многим тебе придется rowpattern в OPENXML рефакторить.

А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован. Т.е. в этом случае в качестве "промежуточного" слоя используется результат работы генератора, который представления одного слоя переводит в представления другого. В нашем случае — сигнатуры СП в C# код. А таких генераторов в инете полным-полно (да и самому слабать труда не составит).

Правда в твоем варианте как бы "автоматизируется" передача сложных объектов одним махом на сервер и освобождает разработчика сложный объект персистить на сервер. В варианте через генерацию в C# код для этого придется повозиться. Или руками. Или создавая тулзу, которая имея описание сложных объектов (хотя бы в виде абстрактных классов или интерфейсов) умеет генерить код построения батча.

kig>>Я смотрю, ты T-SQL писателей за разработчиков не держишь.
M>Еще как держу, пусть делом занимаются, а не параметры в табличку перекладывают...

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

kig>Т.е. СП для работы с композитными объектами (в реляции — мастер-детейл). Правильно понял?
Именно, для простых объектов не имеет смысла канитель с xml-ем затевать...

kig>Т.е. все-таки делать? Блин... опять рантайм.
Ну ясен байт..

kig>"сделаешь deserialize и все косяки тут же вылезут" — это в рантайме
А по другому никак.

kig>Между средами можно по разному передавать. Можно, как предлагаешь ты. Вводя промежуточный слой в виде xml. Но в этом случае ты
kig>откладываешь разбор полетов (ошибки) до момента запуска прилолжения.
Хранимку по другому в принципе не проверишь.

kig> Например, на сложных объектах, если у тебя изменилось 1-ко-многим на многие-ко-многим тебе придется rowpattern в OPENXML рефакторить.
А в классическом варианте ничего рефакторить не придется?

kig>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован.
Каким образом? Он типизирован только по простым типам, string и int, и все, а это не интересно и утомительно.

kig>Правда в твоем варианте как бы "автоматизируется" передача сложных объектов одним махом на сервер и освобождает разработчика сложный объект персистить на сервер.
Вот ради этого все и затевается. Головной боли снимает уйму, проверено...

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

kig>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован. Т.е. в этом случае в качестве "промежуточного" слоя используется результат работы генератора, который представления одного слоя переводит в представления другого. В нашем случае — сигнатуры СП в C# код. А таких генераторов в инете полным-полно (да и самому слабать труда не составит).
Гм. А кто мешает вместо типизированных оберток над sp генерировать тем самым генератором сразу классы, оформленные атрибутами xml-маппинга? Тогда сериализация делается одним движением руки, заполнение данных полностью статически валидируется, и избавляемся от проблем с множественными раунд-трипами. А?

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

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

kig>>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован. Т.е. в этом случае в качестве "промежуточного" слоя используется результат работы генератора, который представления одного слоя переводит в представления другого. В нашем случае — сигнатуры СП в C# код. А таких генераторов в инете полным-полно (да и самому слабать труда не составит).
S>Гм. А кто мешает вместо типизированных оберток над sp генерировать тем самым генератором сразу классы, оформленные атрибутами xml-маппинга? Тогда сериализация делается одним движением руки, заполнение данных полностью статически валидируется, и избавляемся от проблем с множественными раунд-трипами. А?

Да ни кто не мешает. Только в ветке постоянно о СП говорят. Ты сам приводил пример батча, в котором СП.

Если начинать с нуля генераторы писать, по схеме БД просто так маппинг не сгенерить. По сложной БД. По СП — в лет.

"оформленные атрибутами xml-маппинга" — А какой в них смысл? Если уж генерить нормальные орм-классы с полной поддержкой crud, то и атрибуты не нужны. В такие классы необходимо сразу генерить код, который используется для создания батчей.

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

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

kig>>Т.е. СП для работы с композитными объектами (в реляции — мастер-детейл). Правильно понял?
M>Именно, для простых объектов не имеет смысла канитель с xml-ем затевать...

Ну а для составных ИМХО лучше батч. Состоящий из СП, если по религиозным соображениям без не могут, или из обычных dml.
(Я ниже Sinclair отписал по поводу СП. Мы, например, работаем вообще без них.)

kig>>Т.е. все-таки делать? Блин... опять рантайм.
M>Ну ясен байт..

Не гуд...

kig>>"сделаешь deserialize и все косяки тут же вылезут" — это в рантайме
M>А по другому никак.

Тоже не гуд. Уж лучше жесткими типами.

kig>>Между средами можно по разному передавать. Можно, как предлагаешь ты. Вводя промежуточный слой в виде xml. Но в этом случае ты
kig>>откладываешь разбор полетов (ошибки) до момента запуска прилолжения.
M>Хранимку по другому в принципе не проверишь.

А на кой она тогда нужна?

kig>> Например, на сложных объектах, если у тебя изменилось 1-ко-многим на многие-ко-многим тебе придется rowpattern в OPENXML рефакторить.
M>А в классическом варианте ничего рефакторить не придется?

Если нормальный орм — только в тех местах, которые пользуются результатом генерации. Изменилась схема БД, поправили проект орм, получили новые crud-классы. Дальше ловим в компиляции ошибки.

kig>>А можно сгенерить из схемы по СП'ам C# код. И этот код уже жестко типизирован.
M>Каким образом? Он типизирован только по простым типам, string и int, и все, а это не интересно и утомительно.

kig>>Правда в твоем варианте как бы "автоматизируется" передача сложных объектов одним махом на сервер и освобождает разработчика сложный объект персистить на сервер.
M>Вот ради этого все и затевается. Головной боли снимает уйму, проверено...

Только "автоматизируется" по сути выражается через написание ручками соответствующих xpath-выражений в rowpattern.

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

kig>Ну а для составных ИМХО лучше батч.
Автогенеренный? Далеко не всегда подходит, а в рукопашную его пилить — занятие утомительное и от ручного контроля типов не избавляет...

kig>А на кой она тогда нужна?
А на той, что логика хранения данных может довольно серьезно отличаться от вида самих объектов причем так, что никакой генератор не разгребет.
А в таких случаях, либо в рукопашную, либо через xml... Через xml проще.

kig>Только "автоматизируется" по сути выражается через написание ручками соответствующих xpath-выражений в rowpattern.
Да, но это кораздо проще чем каждый параметр в ручную по табличкам раскладывать.

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

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

kig>>Ну а для составных ИМХО лучше батч.
M>Автогенеренный? Далеко не всегда подходит, а в рукопашную его пилить — занятие утомительное и от ручного контроля типов не избавляет...

kig>>А на кой она тогда нужна?
M>А на той, что логика хранения данных может довольно серьезно отличаться от вида самих объектов причем так, что никакой генератор не разгребет.
M>А в таких случаях, либо в рукопашную, либо через xml... Через xml проще.

Пример привел бы. И процент таких ... исключений.
kig>>Только "автоматизируется" по сути выражается через написание ручками соответствующих xpath-выражений в rowpattern.
M>Да, но это кораздо проще чем каждый параметр в ручную по табличкам раскладывать.

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

kig>Пример привел бы. И процент таких ... исключений.
Пример чего?
Ну вот, например, тебе надо порядок изменений таблиц проконтролировать, чтобы на дедлоки или какую несогласованность не нарваться или, упаси байт, хинтом каким воспользоваться и что будет делать генератор?

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

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

kig>>Пример привел бы. И процент таких ... исключений.
M>Пример чего?

Вот этого:


M>А на той, что логика хранения данных может довольно серьезно отличаться от вида самих объектов причем так, что никакой генератор не разгребет.
M>А в таких случаях, либо в рукопашную, либо через xml... Через xml проще.

M>Ну вот, например, тебе надо порядок изменений таблиц проконтролировать, чтобы на дедлоки или какую несогласованность не нарваться

Дык это вопрос инструментария.

M>или, упаси байт, хинтом каким воспользоваться и что будет делать генератор?

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

Ну давай по пунктам:

S>Я, конечно, приводил пример батча. Но ты почему-то напираешь на то, что генератор батча можно генерировать. Справедливость требует отметить, что классы с разметкой для XML -сериализации генерить еще проще.

Что в лоб, что по лбу.
Но то, что создает батч в рантайме, сосредоточено в одном месте.
А в твоем варианте для полноты картины надо не забыть сгенерить СП, которые сериализованные объекты понимают. В результате ты получаешь логику CRUD, размазанную по разным местам. По коду, ну, например C#. И по коду T-SQL. Это не гуд.


kig>>Если начинать с нуля генераторы писать, по схеме БД просто так маппинг не сгенерить. По сложной БД. По СП — в лет.
S>Не, надо наоборот.

Я тебе так и написал — по схеме БД не сгенерить. Информации не хватит.

S>По схеме генерить классы, мапперы, таблички и SP.

Ключевой момент. Вот теперь бы поподробнее, чем и как создается такая схема?

kig>>"оформленные атрибутами xml-маппинга" — А какой в них смысл?
S>Очень простой. Велосипед потому что.

Ну кому что нравится.

kig>>Если уж генерить нормальные орм-классы с полной поддержкой crud, то и атрибуты не нужны. В такие классы необходимо сразу генерить код, который используется для создания батчей.
S>О-о, как круто. При наличии атрибутов код маппинга пишется влет: просто сериализуем класс стандартной сериализацией и отдаем соответствующей хранимке. Имя хранимки — это +1 атрибут. Всё. Упражнение на час. А генератор рукопашной поддержки ОРМ — намного дольше.

Пояснил бы, что такое "рукопашной поддержки".
Кстати, а генерацция "соответсвующих хранимок" это не кусочек ОРМ? И как там с рукопашной поддержкой?