Здравствуйте, IT, Вы писали:
IT>Зачем? Просто не передавай данные, которые не используются.
Во-первых, объявление даже пустых структур анимает место. Кроме того приписывать к классу кучу комментариев — "если объект этого класса возвращён методов А, то поле Б не заполнено" дло ИМХО бесперспективное
Во-вторых бывает обратная ситуация, когда данные передаются, но не хранятся в том виде, в котором передаются.
Здравствуйте, adontz, Вы писали:
A>Во-первых, объявление даже пустых структур анимает место.
Ну и что? Пусть себе занимает, тебе жалко что ли?
A>Кроме того приписывать к классу кучу комментариев — "если объект этого класса возвращён методов А, то поле Б не заполнено" дло ИМХО бесперспективное
А создавать кучу классов и к каждому приписывать где, когда и зачем он используется — это дело перспективное?
A>Во-вторых бывает обратная ситуация, когда данные передаются, но не хранятся в том виде, в котором передаются.
И в чём проблема?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Зачем? Просто не передавай данные, которые не используются.
Ну нельзя так. Об этом уже говорили. В результате мы получаем вообще четырехзначную логику. Да/Нет/Пустое/Не загружен. В результате получается что мы избавляемся от главного плюса business entity — а именно абстрагирование от внутренней структуры объекта. В результате при вызове функции, мы должны всегда будем помнить — загрузили ли мы данные в BE для данной конкретной функции. Упрощения не будет, и как результат — разница между DataSet и business entity нивелируется.
Здравствуйте, IT, Вы писали:
A>>Во-первых, объявление даже пустых структур анимает место. IT>Ну и что? Пусть себе занимает, тебе жалко что ли?
Вобщем-то да, хотя это далеко не главный фактор.
A>>Кроме того приписывать к классу кучу комментариев — "если объект этого класса возвращён методов А, то поле Б не заполнено" дло ИМХО бесперспективное IT>А создавать кучу классов и к каждому приписывать где, когда и зачем он используется — это дело перспективное?
Вполне. Приписывать ничего не надо, так как такие классы — заточенные под определённую цель, локально используемые сущности. Ну и вменяемые имена рулят. Usr32 плохое имя, даже для служебного класса. А Company.Project.Dto.UserLoginRequest вполне хорошее. с таким именем ничего не надо приписывать, и так всё ясно.
A>>Во-вторых бывает обратная ситуация, когда данные передаются, но не хранятся в том виде, в котором передаются. IT>И в чём проблема?
В том, что соответвующего бизнес объекта, пусть даже рыхло заполняемого, просто не существует.
Здравствуйте, GlebZ, Вы писали:
IT>>Зачем? Просто не передавай данные, которые не используются. Z>Ну нельзя так. Об этом уже говорили. В результате мы получаем вообще четырехзначную логику. Да/Нет/Пустое/Не загружен. В результате получается что мы избавляемся от главного плюса business entity — а именно абстрагирование от внутренней структуры объекта.
Об обратной стороне медали мы тоже уже говорили — на каждый новый запрос нам понадобится новая сущность.
Z>В результате при вызове функции, мы должны всегда будем помнить — загрузили ли мы данные в BE для данной конкретной функции. Упрощения не будет, и как результат — разница между DataSet и business entity нивелируется.
Это всё теоретические домыслы. На практике ничего помнить не надо. Случаи, когда некоторые поля игнорируются в основном связаны с отображением данных в гридах. При этом как правило под такое отображение пишется специфический запрос начиная с клиента и заканчивая БД. Если тебе вдруг захочется отобразить дополнительное поле и его не окажется в ответе сервера, то такая вещь выплывет мгновенно и чтобы её поправить нужно будет лишь включить ещё одно поле в запрос БД.
В общем, мы поехали по второму кругу.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>>>Во-первых, объявление даже пустых структур анимает место. IT>>Ну и что? Пусть себе занимает, тебе жалко что ли? A>Вобщем-то да, хотя это далеко не главный фактор.
А какой главный?
IT>>А создавать кучу классов и к каждому приписывать где, когда и зачем он используется — это дело перспективное?
A>Вполне. Приписывать ничего не надо, так как такие классы — заточенные под определённую цель, локально используемые сущности. Ну и вменяемые имена рулят. Usr32 плохое имя, даже для служебного класса. А Company.Project.Dto.UserLoginRequest вполне хорошее. с таким именем ничего не надо приписывать, и так всё ясно.
Для логина, как мы уже выяснили, никакого объекта не надо вообще. Для остальных случаев твои имена будут конечно же не User1, User2... Они будут UserForForm1, UserForForm2 и т.п. Т.е. для каждого конкретного случая тебе понадобится новый класс. При этом, даже если стурктуры вдруг случайно совпадут, то тебе всё равно придётся создавать новый класс, т.к вполне вероятно, что тебе придётся изменить один из них в будущем и тогда некоторые в одном из случаев поля останутся пустыми, что по твоей теории недопустимо.
A>>>Во-вторых бывает обратная ситуация, когда данные передаются, но не хранятся в том виде, в котором передаются. IT>>И в чём проблема? A>В том, что соответвующего бизнес объекта, пусть даже рыхло заполняемого, просто не существует.
И в чём проблема?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A> С другой плохо, потому что с инкапсуляция тю-тю.
Почему это? Просто вся логика вынесена в сервисные классы бизнес-слоя, где ей вообщем-то и место, там она и инкапсулируется... Что такого нетривиального содержится в бизнес-объекте User, что должно быть инкапсулировано? Сам по себе он логики не содержит, там нечего скрывать.
A> С двумя полями OldPassword и NewPassword?
Зачем? OldPassword и NewPassword отлично передаются в обычных строках... Хотя это конечно тоже можно считать в некотором роде DTO.. =)
A> Хоть все методы оттуда выкинь, если есть передача частичных, неполных, нехранимых данных,
Я, на самом деле, не придерживаюсь столь радикальной точки зрения как Игорь, но есть одно жизненное наблюдение... Если позволишь, аналогию проведу: в физике, еще в школе учили одному хорошему правилу — если есть задачка и кажется, что данных не хватает — решай задачу с теми данными, которые есть, скорее всего окажется, что лишние переменные просто сократятся.... Так и здесь — когда все четко распишешь, то в большинстве случаев оказывается, что все что хотелось сделать DTO, и так есть в бизнес-объектах (которые, естественно, не содержат логики), а что осталось вполне можно передать в примитивных типах.
A> Мне кажется избыточность протокола больше повлияет на производительность.
Ну, во-первых никакой избыточности на самом деле нет, а во вторых, на производительность, если говорить о сети, гораздо больше влияет частота запросов, в виду ее латентности, нежели размер передаваемых данных. В этом разрезе скорее окажется выгоднее один раз передать 1000 байт, чем три раза по 10. Но это уже отдельный вопрос.. )
Здравствуйте, IT, Вы писали:
IT>Зачем? Просто не передавай данные, которые не используются.
Давай вернёмся к примеру. Ты хочешь сказать, что нужно описать класс, который будет содержать все мыслимые данные на все случаи жизни, а затем использовать его во всяких вызовах, но заполнять поля "по требованию"?
Типа, надо только ID — заполнили в методе слоя логики ID, но передали класс целиком (в др. полях null), надо ID и DisplayName — вернули их. Так, я правильно понял?
И накладными расходами можно пренебречь?
class User
{
public int ID { get; }
public string SystemName { get; }
public string DisplayName { get; }
}
class UserManager
{
public void ChangePassword(int userID, string oldPassword, string newPassword);
public User GetUser(int userID);
public List<User> GetUserList();
}
Здравствуйте, IT, Вы писали:
IT>>>Зачем? Просто не передавай данные, которые не используются. Z>>Ну нельзя так. Об этом уже говорили. В результате мы получаем вообще четырехзначную логику. Да/Нет/Пустое/Не загружен. В результате получается что мы избавляемся от главного плюса business entity — а именно абстрагирование от внутренней структуры объекта. IT>Об обратной стороне медали мы тоже уже говорили — на каждый новый запрос нам понадобится новая сущность.
Смотря какой запрос. Что касается запроса сервера баз данных — то тут будет избыточность получаемых данных, и это нормально. Что касается запросов к серверу — надо думать в каждом конкретном случае.
Z>>В результате при вызове функции, мы должны всегда будем помнить — загрузили ли мы данные в BE для данной конкретной функции. Упрощения не будет, и как результат — разница между DataSet и business entity нивелируется. IT>Это всё теоретические домыслы.
Окей. Как бы ты решал аналогичную задачу?
[Flags]
public enum DogLoadMode
{
Dog,
Foots,
Head,
Nose,
Tail
}
public string GetDog(string id, DogLoadMode loadMode)
{
Stream stream=DTOHelper.CreateStream();
if ((loadMode&DogLoadMode.Dog)!=0)
DTOHelper.Serialize(stream, Dogs.GetDogById(id));
if ((loadMode&DogLoadMode.Foots)!=0)
DTOHelper.Serialize(stream, Foots.GetFootsByDog(id));
if ((loadMode&DogLoadMode.Head)!=0)
DTOHelper.Serialize(stream, Heads.GetHeadByDog(id));
if ((loadMode&DogLoadMode.Nose)!=0)
DTOHelper.Serialize(stream, Noses.GetNoseByDog(id));
if ((loadMode&DogLoadMode.Tail)!=0)
DTOHelper.Serialize(stream, Tails.GetTailByDog(id));
return DTOHelper.StreamToString(stream);
}
Здравствуйте, IT, Вы писали:
IT>Таким образом DTO можно обозвать всё что угодно, даже пакеты TCP. А назвав всё что можно DTO мы начинаем пихать его куда ни поподя уже не понимая нужно оно там или нет. Твой пример с ChangePassword это очень хорошо демонстрирует. Там где можно обойтись тремя параметрами ты создал целый класс. Класс здесь, класс там, а потом мы удивляемся почему сложность системы выходит из под контроля.
Ок. Но как же быть с технологиями которые предполагают и рекомендуют использование DTO? Взять тот же WCF, например... Ведь дата контракты это чистейшей воды DTO.
Вот возьмем к примеру многоуровневое и распределенное приложение которое использует WCF и "легкие" сущности. Так мы можем дойти до ситуации когда на каждом свойстве наших сущностей будет навешано до десятка атрибутов (валидация, дата контракт, маппинг бд и т.д.). А эти атрибуты определены в других сборках которые тоже надо тащить по всем уровням. Все это увеличивает связность приложения.
В этом случае не лучше ли будет разделить сущности и раздать им ту функциональность которая необходима на конкретном уровне? Клиентским сущностям привязка к UI и простая валидация, серверным — маппинг в базу данных, валидация уровня бизнес логики и DTO для передачи по WCF. Все это уменьшит связность уровней и четко очертит зоны применения конкретных сущностей. Разве это сделает систему сложней? Или увеличит сложность поддержки?
Hello, "GlebZ"
> Окей. Как бы ты решал аналогичную задачу?
Задачка из разряда "специально не придумаешь" Это, что реальный код? Что в итоге возвращает метод GetDog? С одной стороны вроде как собаку. Но, почему тогда в виде строки... С другой стороны, если посмотреть глубже то вроде как возвращает он не только собак но и носы, хвосты и т.п...
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Задачка из разряда "специально не придумаешь" Это, что реальный код? Что в итоге возвращает метод GetDog? С одной стороны вроде как собаку. Но, почему тогда в виде строки...
А какая разница? В виде строки XML, в виде объекта, в виде ... От этого смысл не меняется. Важно то, что вконкретном примере объекты при переносе становятся стримом. TK>С другой стороны, если посмотреть глубже то вроде как возвращает он не только собак но и носы, хвосты и т.п...
Не носы и хвосты, а конкретный нос и конкретный хвост(если он вообще есть) конкретной собаки.
Я просто попросил сделать аналогичную задачу по той методике которую использует IT. Или, например, ты?
Здравствуйте, akasoft, Вы писали:
A>Давай вернёмся к примеру. Ты хочешь сказать, что нужно описать класс, который будет содержать все мыслимые данные на все случаи жизни, а затем использовать его во всяких вызовах, но заполнять поля "по требованию"?
Нет, я не хочу сказать, что класс будет содержать все мыслимые данные на все случаи жизни. Это тоже самое, что сказать, что одна таблица базы данных будет содержать все данные приложения. Бред, не так ли? Конечно же так никто не делает. Более того, на практике часто получается, что объектная модель приложения несколько отличается от модели БД и вполне допустимо, что разные сущности приложения являются либо подмножеством какой-либо таблицы, либо, чаще, комбинацией данных из нескольких таблиц и/или агрегированных данных. Как правило, такая модель содержит минимум необходимых сущностей, которые покрывают 90% функциональности приложения. Остальные 10% — это где-то местами неиспользуемые поля.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, varely, Вы писали:
V>Ок. Но как же быть с технологиями которые предполагают и рекомендуют использование DTO? Взять тот же WCF, например... Ведь дата контракты это чистейшей воды DTO.
Кто это сказал?
V>Вот возьмем к примеру многоуровневое и распределенное приложение которое использует WCF и "легкие" сущности. Так мы можем дойти до ситуации когда на каждом свойстве наших сущностей будет навешано до десятка атрибутов (валидация, дата контракт, маппинг бд и т.д.). А эти атрибуты определены в других сборках которые тоже надо тащить по всем уровням. Все это увеличивает связность приложения.
Очень хороший вопрос. Главное конкретный, а не высосанный из пальца. На конкретный вопрос можно привести конкретный пример.
Всё зависит где и зачем используется WCF. Если это часть внутреннего приложения, то я бы не стал заморачиваться отдельными DTO. Или возьмём, к примеру, тот же янус. Контракт, предоставляемый сервером можно было сделать на DTO, но на практике это никаких преимуществ не даст. Вообще никаких. Но сложность сопровождения увеличит. Нужны нам здесь отдельные DTO? Я думаю вряд ли. Теперь возьмём, например, банковскую систему, которая предоставляет некоторую информацию клиентам. Имеет ли здесь выставлять на показ потроха нашей системы? Не имеет. Здесь можно было бы воспользовать DTO. Но! Есть один момент. Скорее всего, на 99%, такая система будет придоставлять данные в виде XML, а следовательно все атрибуты, навешанные на бизнес сущности просто элементарно будут отсечены. Имеет ли смысл в этом случае городить огород? Не знаю, надо разбираться с конкретной задачей.
V>В этом случае не лучше ли будет разделить сущности и раздать им ту функциональность которая необходима на конкретном уровне? Клиентским сущностям привязка к UI и простая валидация,
Клиентская валидация в большинстве случаев делается с помощью контролов. Базовая валидация вообще скорее всего совпадает с серверной базовой валидацией. Странно предположить, что, например, на клиенте длина строки должна быть не более 50-ти строк, а вот на сервере уже не более 40-ка. А раз так, то вполне логично определить такое правило один раз в одном месте, а не на каждом уровне.
V>серверным — маппинг в базу данных, валидация уровня бизнес логики и DTO для передачи по WCF. Все это уменьшит связность уровней и четко очертит зоны применения конкретных сущностей.
Зона применения конкретной сущности не слой, а функция, выполняемая системой. Т.е. мы имеем не горизонтальное по слоям, а вертикальное по функциональности деление. В большинстве приложений 80-90% обращений к серверу представляют собой переадресацию запроса по слоям до самой БД, выборку данных и обратный процесс доставки данных на клиента. Какой смысл переливать данные из одного формата в другой на каждом уровне?
V>Разве это сделает систему сложней? Или увеличит сложность поддержки?
Конечно увеличит. Давай сравним. Допустим нам нужно отобразить список пользователей на гриде. Вот минимальное решение.
BE:
class User
{
public string FirstName;
public string LastName;
}
UI:
class UserListDialog
{
public void OnLoad()
{
binder.List = new UserManager().GetUserListByCriteria(...);
}
}
BL:
class UserManager
{
public List<User> GetUserListByCriteria(...)
{
return UserAccessor.GetUserListByCriteria(...);
}
}
DAL:
class UserAccessor
{
public List<User> GetUserListByCriteria(...)
{
return GetAndMapData("SELECT * FROM User WHERE...", ...);
}
}
Всё просто, я бы даже сказал примитивно. Если бы не дань традициям, то UserManager.GetUserListByCriteria вообще можно было бы опустить, унаследовав UserManager от UserAccessor.
Теперь напишем вариант с перекладыванием данных:
UI:
class UserUI
{
public string FirstName;
public string LastName;
}
class UserListDialog
{
public void OnLoad()
{
List<UserDTO> userDTOs = new UserManager().GetUserListByCriteria(...);
List<UserUI> userUIs = Map(userDTOs);
binder.List = userUIs;
}
}
BL:
class UserDTO
{
public string FirstName;
public string LastName;
}
class UserObject
{
public string FirstName;
public string LastName;
}
class UserManager
{
public List<UserDTO> GetUserListByCriteria(...)
{
List<UserObject> users = UserAccessor.GetUserListByCriteria(...);
List<UserDTO> userDTOs = Map(users);
return userDTOs;
}
}
DAL:
class UserAccessor
{
public List<UserObject> GetUserListByCriteria(...)
{
return GetAndMapData("SELECT * FROM User WHERE...", ...);
}
}
Невооружённым глазом видно, что логика приложения увеличилась. Введение новых сущностей потребовало дополнительного шага — маппинга из одного формата в другой. Оставим эту задачу в покое, заметим лишь, что иногда само по себе решение этой задачи может потребовать дополнительных сил и напряжения.
Но это ещё не всё. Допустим в процессе сопровождения нам понадобилось добавить ещё одну колонку MiddleName. Для того, чтобы это сделать, мне нужно будет добавить эту колонку в БД, на форму и в BE User. Тебе — в БД, на форму, в классы UserObject, UserDTO, UserUI. Если у тебя больше слоёв, значит во все существующие. Учитывая, что реальные приложения многократно сложнее этого примера, то и количество телодвижений пропорционально увеличивается, увеличивается запутанность кода, что в свою очередь приводит лавинообразному процессу и выхода сложности системы из под контроля.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
V>>серверным — маппинг в базу данных, валидация уровня бизнес логики и DTO для передачи по WCF. Все это уменьшит связность уровней и четко очертит зоны применения конкретных сущностей.
Да... ещё забыл насчёт связности. Какой из примеров теперь выглядит более связным?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>public Dog GetDog(string id)
IT>{
IT> return DogAccessor.GetWholeDog(id);
IT>}
IT>
IT>Код проще,
Код действительно проще. Но не для клиента. IT>обращений к БД меньше.
Это не есть верно. Если при нагрузочном тестировании я решу что при загрузке собаки часто используется какие-то доп. сущности и латентность запросов БД влияет на производительность — я могу загружать одновременно их в один запрос. Метод GetDogById etc — это запрос к базе только если он не был загружен ранее в том же контексте запроса сервера (или нет более сложной системы). То есть, у меня есть возможность более гибко управлять системой в отличие от твоего способа. Потому как если кроме собаки появится сороконожка, то мы вполне можем положить сервер.
Здравствуйте, GlebZ, Вы писали:
IT>>обращений к БД меньше. GZ>Это не есть верно. Если при нагрузочном тестировании я решу что при загрузке собаки часто используется какие-то доп. сущности и латентность запросов БД влияет на производительность — я могу загружать одновременно их в один запрос.
Я думаю, что не всё так просто. Иначе бы ты привёл такой код сразу. Не так ли?
GZ>Метод GetDogById etc — это запрос к базе только если он не был загружен ранее в том же контексте запроса сервера (или нет более сложной системы). То есть, у меня есть возможность более гибко управлять системой в отличие от твоего способа.
Гибкость хороша когда она востребована. В моём примере она просто не нужна. А раз так, то учитывая, что плата за гибкость есть усложнение системы, то твоё решение не обладая никакими преимуществами является более сложным и трудно сопровождаемым.
GZ>Потому как если кроме собаки появится сороконожка, то мы вполне можем положить сервер.
Вот когда появится сороконожка, тогда мы с ней и будем разбираться. А пока давай о собаке.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Да... ещё забыл насчёт связности. Какой из примеров теперь выглядит более связным?
Что значит выглядит? Твой пример более связный. Допустим, оказалось что агрегирующий запрос по количеству писем отправленных пользователем подсаживает базу данных. И неплохо было бы реализовать агрегат тригерами на новое поле в пользователе. Как бы чистая проблема сервера. Но в твоем случае — оно затронет клиента.
К тому же не забывай. Если DTO объект полностью равнозначен BE то можно воспользоваться BE для сериализации. Если он перестал нас удовлетворять как DTO, то мы вполне можем ввести свой custom объект.
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
Это, что реальный код? Что в итоге возвращает метод GetDog? С одной стороны вроде как собаку. Но, почему тогда в виде строки... С другой стороны, если посмотреть глубже то вроде как возвращает он не только собак но и носы, хвосты и т.п...
В виде строки XML, в виде объекта, в виде ... От этого смысл не меняется. Важно то, что вконкретном примере объекты при переносе становятся стримом.
