• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Auto mapper public
 

Auto mapper public

on

  • 425 views

 

Statistics

Views

Total Views
425
Views on SlideShare
425
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Как и в любой другой профессии, прогресс в программировании достигается толь­ко путем обучения (т.е. путём получения получения знаний), причем основынных как на ошибках, так и на удачах — и своих и чужих. В совоём докладе я постараюсь сложить общие знания полученные мной, как из практики, так и из литературы и показать, что иссопльзование инструментов O-to-O маппинга очень полезно в самых разнообразные проектах и системах связанных с разработкой ПО. Целью этого доклада является не глубокий анализ инструментов, а показ их базовых возможностей и представление самой концепции O-to-O маппинга.
  • Безусловно разработка програмного обеспечения - сложный процесс, в течении которого все вовлечённые в него люди сталкиваются с решением разнообразных задач и преодаливают препятсвия разного рода и характера.Но мы также знаем, что не все программные системы сложны. Существует множество программ, которые задумываются, разрабатываются, сопровождаются и используются одним и тем же человеком. Обычно это начинающий программист или профессионал, работающий изолированно.Я не хочу сказать, что все такие системы плохо сделаны или, тем более, усомниться в квалификации их создателей. Но такие системы, как правило, имеют очень ограниченную область применения и короткое время жизни. Обычно их лучше заменить новыми, чем пытаться повторно использовать, переделывать или расширять. Другое дело те программы, которые мы назывемпромышленными программными продуктами. Они применяются для решения самых разных задач, таких, например, как системы с обратной связью, которые управляют или сами управляются событиями физического мира; задачи поддержания целостности информации объемом в сотни тысяч записей при параллельном доступе к ней с обновлениями и запросами; системы управления и контроля за реальными процессами (например, диспетчеризация воздушного или железнодорожного транспорта, медецина), корпоративные приложения (сложность которых обусловленна изо­щренными данными большого объема и бизнес-правилами, логика которых иногда про­сто противоречит здравому смыслу). Системы подобного типа обычно имеют большое время жизни, и большое количество пользователей оказывается в зависимости от их нормального функционирования.Существенная черта промышленной программы - уровень сложности: один разработчик практически не в состоянии охватить все аспекты такой системы. Грубо говоря, сложность промышленных программ превышает возможности человеческого интеллекта. Увы, но сложность, о которой мы говорим, повидимому, присуща всем большим программных системам. Говоря "присуща", я имею в виду, что эта сложность здесь неизбежна: с ней можно справиться, но избавиться от нее нельзя.Конечно, среди нас всегда есть гении, которые в одиночку могут выполнить работу группы обычных людей-разработчиков и добиться в своей области успеха, сравнимого с достижениями Леонардо да Винчи или Исаака Ньютона. Такие люди нам нужны как архитекторы, которые изобретают новые идиомы, механизмы и основные идеи, используемые затем при разработке других систем. Однако, в мире очень мало гениев, и не надо думать, будто в среде программистов их доля выше средней. Несмотря на то, что все мы чуточку гениальны и при нашествии вдохновения многие из нас могут свернуть горы, в промышленном программировании нельзя постоянно полагаться на божественное вдохновение, которое обязательно поможет нам. Поэтому мы исспользуем более надежные способы управления конструированием сложных систем.Основной способуправления конструированием сложных систем был известен еще в древности – и этот способ назыавется divide and conquer (разделяй и властвуй). При проектировании сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо. В этом случае мы не превысим пропускной способности человеческого мозга: для понимания любого уровня системы нам необходимо одновременно держать в уме информацию лишь о немногих ее частях (отнюдь не о всех).
  • Я не буду вдаваться в подробности и рассказывать о каждом понятии указанном на этом слайде, я привёл их сдесь, как сгруппированные знания, которые, в моём понимании, являются базой для современной и успешной разработки ПО.Хочется остановиться на следующих и задать вопрос аудитории:OOA, OOD, OOP, DDD, UML, PATTERNS – что объеденяет все эти понятия? Правильно, все эти понятия объяденяются абстрагированием. Абстрагирование является одним из основных методов, используемых для решения сложных задач.
  • Модель представ­ляет собой специально отобранный и сознательно упрощенный запас знаний в структу­рированной форме.
  • DDD layers:PresentationApplicationServiceDomainDTOДостоинства:Спрятанные деталиРазглаживание серии связанных бизнес сущностейУменьшенное колличество вызовов на уровне данныхНедостаткиУвелечение колличества классов и соответсвенно затраты на кодированиеДополнительные вычисленя
  • Flattening – сплющивание, разглаживание. Just a abstract sample.

Auto mapper public Auto mapper public Presentation Transcript

  • Object-to-objectmapping © Oleksii Dukhno @ Lohika Systems
  • Complexity of software
  • Tools for fighting with thecomplexity
  • Abstractions and model
  • Models, DTO and ViewModels data transfer object = model data only view model = model data + behavioral aspects data transfer object != view model but view model = data transfer object
  • Models, DTO and ViewModels Flattening
  • Why using o-2-o ? Encapsulate Flattening Logic
  • Why using AutoMapper ? Encapsulate Flattening Logic Result = Neater code, Simpler support, Better understanding
  • How to use AutoMapper ? Mapping Mapping Test Through Through Mapping Convention Configuration Projection Validate Source/Destination Configuration Properties Names Convention Value Resolver Type Converter Ignore
  • Mapping Through Convention
  • Mapping Through Configuration IgnoreWill throw AutomapperConfigurationException
  • Mapping Through Configuration Ignore
  • Mapping Through Configuration Projection
  • Mapping Through Configuration Projection
  • Mapping Through Configuration Type Converter
  • Mapping Through Configuration Type Converter
  • Mapping Through Configuration Value Resolver
  • Mapping Through Configuration Value Resolver
  • Mapping Through Configuration Value Resolver
  • Using AutoMapper in Allocine-CMS
  • Using AutoMapper in Allocine-CMS
  • Emit Mapper Key Sufficiencies Really fast (close to hand written code) Supports mono
  • Emit Mapper - simplest example CODE
  • Emit Mapper – custom converter  CODE
  • Emit Mapper – post processing CODE
  • Emit Mapper vs. AutoMapper Style Facade Speed Open Source ReliabilityEmit Mapper Functional No The Best Yes LowAutoMapper OO Yes Good Yes High