Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sander Hoogendoorn Principal Technology Officer Capgemini The Netherlands SESSION CODE: ARC303.

Similar presentations


Presentation on theme: "Sander Hoogendoorn Principal Technology Officer Capgemini The Netherlands SESSION CODE: ARC303."— Presentation transcript:

1 Sander Hoogendoorn Principal Technology Officer Capgemini The Netherlands SESSION CODE: ARC303

2

3

4

5

6

7

8 It always takes longer than you expect, even when you take into account Hofstadter’s Law

9

10 Frameworks, like pizzas, only come in only two sizes: too big and too small.

11

12

13 General Purpose Frameworks Enterprise Library, Spring.Net, Castle, NakedObjects, ADF, SubSonic, … General Purpose Frameworks Enterprise Library, Spring.Net, Castle, NakedObjects, ADF, SubSonic, … Single goaled frameworks – verticals Dependency injection: ObjectBuilder, Unity, Castle Windsor, (MEF) Logging: Log4Net, Logging Block, Common.Logging Exception handling: Exception Handling Block Apect orientation: PostSharp, SetPoint Search: Lucene.net, NLucene Portals: DotNetNuke, Umbraco, Orchard CMS Single goaled frameworks – verticals Dependency injection: ObjectBuilder, Unity, Castle Windsor, (MEF) Logging: Log4Net, Logging Block, Common.Logging Exception handling: Exception Handling Block Apect orientation: PostSharp, SetPoint Search: Lucene.net, NLucene Portals: DotNetNuke, Umbraco, Orchard CMS Single goaled frameworks – architectural User interface: Silverlight, ASP.NET MVC, WPF, ASP.NET Ajax, Spring MVC Process: UI Process Application Block, WF Domain: Entity Framework, NHibernate, NEO Data: Entity Framework, Hibernate, Castle ActiveRecord, CSLA Services: WCF, WCF RIA Single goaled frameworks – architectural User interface: Silverlight, ASP.NET MVC, WPF, ASP.NET Ajax, Spring MVC Process: UI Process Application Block, WF Domain: Entity Framework, NHibernate, NEO Data: Entity Framework, Hibernate, Castle ActiveRecord, CSLA Services: WCF, WCF RIA

14

15

16

17

18

19

20

21

22

23

24

25

26 The way out of trouble is never as simple as the way in.

27 What if we require additional features that aren’t covered by our framework? What if we decide that another framework might be better than the one we’re using now? What if the author of our favorite framework suddenly stops developing it? What if the framework contains bugs? And what if the new version of our framework is implemented totally different?

28

29 An application developer An application developer A framework developer A framework developer

30

31

32

33 I don’t care if it works on your machine! We are not shipping your machine! Here’s … beta!

34

35

36

37

38 Only in theory, practice and theory are the same

39

40

41

42

43

44 End of lifecycle?

45

46

47

48 Some basic patterns that might help you

49 Dependencies  Using frameworks is simply good, gringo  However, be very aware of dependencies Minimize dependencies  Frameworks reflect software architecture, not vice versa  Define your own layer supertypes  Apply dependency injecton / extensibility  Apply additional patterns  Many more patterns, some very basic, will increase minimizing dependencies

50 Architecture starts when you carefully put two bricks together. There it begins.

51

52 Presentation Process Domain Data / Services Outside world Pages UserControls Panels Use cases Workflow Domain objects / Entities Factories / Repositories Enums / Value objects / Smart references [Mapping] Service gateways Service locators [Mapping] Databases Services / ESB PeoplesoftSAPBizTalkJava Software architecture vs frameworks Software architecture is leading Layers, elements, responsibilities, collaboration Frameworks supports architecture! Code reflects architecture Software architecture vs frameworks Software architecture is leading Layers, elements, responsibilities, collaboration Frameworks supports architecture! Code reflects architecture

53 From a programmer's point of view the user is a peripheral that types when you issue a read request.

54 What’s a layer supertype Ollie?  Acts as a supertype for all types in its layer  All types inherit from the layer supertype Well Stan, it’s characteristics are  Name expresses common behaviour  Forces common features on all inherited types  Ideal starting point for services  Initially the layer supertype is empty  Reserve layer supertype for future additions  Extension methods don’t (always) help, you know

55

56

57

58

59

60

61

62

63

64 Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

65 What is the matter Mister Fawlty? The problem Manual, is that  I want to use constants in my application  But I want to define them in my framework and extend them in my application  Enumeration won’t do – there’s no inheritance [PrincipalPermission(SecurityAction.Demand, Role = "Teller")]

66

67

68 Descriptor Defines a restricted but application specific extendible list of definitions Useful when  Enums can not be inherited  Framework defines enumeration types that need to be extended in application code  Define layer supertype using reflection  Pre-define frequently used instances [PrincipalPermission(SecurityAction.Demand, Roles.Teller)]

69

70

71

72

73

74

75 XML is like violence - if it doesn’t solve your problems, you are not using enough of it.

76 What do you think it is? Create true separation between definition and implementation, so that the two can vary independently and can be replaced easily Looks like a typical case of dependency injection to me  Call functionality without having to know the actual implementation  Implement replaceable services  Apply implementations in different contexts  Plug-in services at run-time So …  Single topic services  Single or multiple implemenations need to be handled, which differs dependant on context, like with Windows API, logging or error handling  Unit testing

77 Did you know that there are different types of this dependency injection? Arggh… Yeah, sure. There’s  Constructor injection  Property (setter) injection  And even manual injection  Extending MEF style? Who cares doc?

78

79 Yes, XML will hurt you too!

80 "Teamwork is a lot of people doing what I say“

81 Definition  The manager-provider pattern creates a simple facade for a (set of) interfaced implementation(s) In practice  Facade holding one or a collection of instances of a particular interface  Methods to call methods from interface  At run-time, using dependency injection, actual implementation are injected Useful when  Generic services need to be called, which may have different implementations  Manager prevents having to loop through each of a list of implementation  Flexibility to add or remove implementation without change the application code

82

83

84

85

86

87

88 Dependencies  Using frameworks is simply good, gringo  However, be very aware of dependencies Minimize dependencies  Frameworks reflect software architecture, not vice versa  Define your own layer supertypes  Apply dependency injecton / extensibility  Apply additional patterns  Many more patterns, some very basic, will increase minimizing dependencies

89

90

91

92 www.accelerateddeliveryplatform.com www.sanderhoogendoorn.com or sander.hoogendoorn@capgemini.com LinkedIn: aahoogendoorn Twitter: @aahoogendoorn

93 www.microsoft.com/teched www.microsoft.com/learning http://microsoft.com/technet http://microsoft.com/msdn

94

95 Sign up for Tech·Ed 2011 and save $500 starting June 8 – June 31 st http://northamerica.msteched.com/registration You can also register at the North America 2011 kiosk located at registration Join us in Atlanta next year

96

97


Download ppt "Sander Hoogendoorn Principal Technology Officer Capgemini The Netherlands SESSION CODE: ARC303."

Similar presentations


Ads by Google