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

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

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

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

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

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?

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

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

Only in theory, practice and theory are the same

End of lifecycle?

Some basic patterns that might help you

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

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

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

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

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

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

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")]

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)]

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

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

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?

Yes, XML will hurt you too!

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

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

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

or LinkedIn: aahoogendoorn

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