Auto mapper public

584 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
584
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Как и в любой другой профессии, прогресс в программировании достигается толь­ко путем обучения (т.е. путём получения получения знаний), причем основынных как на ошибках, так и на удачах — и своих и чужих. В совоём докладе я постараюсь сложить общие знания полученные мной, как из практики, так и из литературы и показать, что иссопльзование инструментов 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

    1. 1. Object-to-objectmapping © Oleksii Dukhno @ Lohika Systems
    2. 2. Complexity of software
    3. 3. Tools for fighting with thecomplexity
    4. 4. Abstractions and model
    5. 5. 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
    6. 6. Models, DTO and ViewModels Flattening
    7. 7. Why using o-2-o ? Encapsulate Flattening Logic
    8. 8. Why using AutoMapper ? Encapsulate Flattening Logic Result = Neater code, Simpler support, Better understanding
    9. 9. 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
    10. 10. Mapping Through Convention
    11. 11. Mapping Through Configuration IgnoreWill throw AutomapperConfigurationException
    12. 12. Mapping Through Configuration Ignore
    13. 13. Mapping Through Configuration Projection
    14. 14. Mapping Through Configuration Projection
    15. 15. Mapping Through Configuration Type Converter
    16. 16. Mapping Through Configuration Type Converter
    17. 17. Mapping Through Configuration Value Resolver
    18. 18. Mapping Through Configuration Value Resolver
    19. 19. Mapping Through Configuration Value Resolver
    20. 20. Using AutoMapper in Allocine-CMS
    21. 21. Using AutoMapper in Allocine-CMS
    22. 22. Emit Mapper Key Sufficiencies Really fast (close to hand written code) Supports mono
    23. 23. Emit Mapper - simplest example CODE
    24. 24. Emit Mapper – custom converter  CODE
    25. 25. Emit Mapper – post processing CODE
    26. 26. Emit Mapper vs. AutoMapper Style Facade Speed Open Source ReliabilityEmit Mapper Functional No The Best Yes LowAutoMapper OO Yes Good Yes High

    ×