dotNETwork 10th: Architecture Speaking for Itself (DI / AOP)

As ever, there’s

The usual intro …

The .NETwork day for December that took place this Saturday as the 10th group gathering/event was pretty much worth being the day that makes a whole year for .NETwork group, which started December 2007. The day was pretty much different than usual, maybe similar to the very first gathering in organization, and some other days in topic, but the style and taste was a bit different. Pretty much concentrated, although on a variety of topics.

The day was just a couple of sessions. Love it or hate it, no parallelism there. The sessions were given by a single speaker, Omar Besiso, a half Egyptian senior Architect living in Australia, a consultant, Tech Ed presenter, book editor and reviewer – a very great guy as I’ll explain later :).

Actually I really enjoyed the first session. Really want to attend / give many similar sessions in the future.


I have not been very honest while writing this! Since I have a similar interest in the topics discussed during the session, I have written some parts of the post that were not said during the presentation the same way,a and provided some examples and such that represent my own understanding which may or may not be the same as Omar’s.


Lets give it a strong start :-) …

… On Architecture

“Who here is an architect, or works as an architect?”

Having a very quick meal just before entering getting us exactly a minute late (me and Mohamed Samy, my dear friend, without getting lost in the way this time), and before we finish plugging in our laptops and firing OneNote, we were hit by the question as the true start of the session.

Of course I and M. Samy stood for it. This led us to talking about what an architect does exactly. the short answer is “everything”. He designs applications, interfacing between those applications. He meets customer. He still writes code and maybe Prototype or Proof of Concept. But there are types of software architects:

  • Solution Architect: Close to the team decided to work on the solution, performs architecture for a specific solution.
  • Enterprise Architect: This is the one that does everything communications to the office boy and to the CEO. In other words, he handles the solution from the very beginning of whether to have a single solution or series of connected ones.

That talk was before Omar introduces his work-in-progress book “Reactive Programming & Domain Driven Design”, speaking on himself as a “Not technologist.,, but very low Java IQ” (It was interesting to know such exists!). This means that he has no special feeling about any specific .NET technology, or a language, and this is very important, to be able to mentally choose the right technology for the right situation (he made another statement that he uses SharePoint whenever the budget allows, plain ASP.NET only otherwise, which is another interesting topic). However, this is all on top of the .NET platform, as “The technology-Independent architecture that we heard of in the 90s is no longer a fact”.

… On Architecture Myths and Data Driven Architecture

Those are the things most people believe in and do, while are no longer relevant to today’s and future architecture.

  • Myth No.1: 3 Tier Architecture
    • You know this  UI –> Business -> Data thingy!
    • Of course we today know we need other layers
    • How about logging, where does it fit here. Object Pooling, etc…
  • Myth No.2: N Tier Architecture
    • There are so many styles, but usually that’s what it ends to: UI -> External Service –> Business –> Internal Service –> Data
    • The point is, as in the next myth, that is all goes in circles around data.
  • Myth No.3: Data Driven Architecture
    • Bring the DB, fire up the DAL generator, build some “business” that just calls this and bake some UI for it.
    • The argument here was: what if you do not have exactly a database. How about things like Office or Photoshop or so.
    • “We use CodeSmith/.NETTiers as our architecture” What a statement. Is code generation exactly an architecture?
  • Myth No.4: Architecture and design are an overhead
    • Architecture is like an investment. Omar quotes: “If every investment is an overhead, it’s time to sell your assets”. To be fair, I mention he has been working with big projects of hundreds of developers still in one project.
    • The point is about maintenance and updates that takes most of the real time of a project. It’s about responding to change, and the time it takes to actually do respond to that change.
      • For example, for an interest rate value to change, this may be as easy in your design as changing a configuration value, but, how about changing the way this interest rate value is used or the interest way of calculation?
    • Side Arguments:
      • A bad architecture can cost an entire rewrite of the whole solution from scratch not even parts of it. Sometimes if things go bad such a decision is the right one to have.
      • No university on earth teaches the “right” software engineering! Even MIT has hundreds of methodologies, that you don;t know which to follow.
      • “Do not let a software engineer build your house”, you cannot afford a bug or rebuild in there ;).

Clearly, Omar is against the Database-First approach. I heard the same things many time on ALT.NET threads, and it takes many posts to talk about without much benefit, but anyway, Omar’s main argument is that you heart your model (say the classes you use to represent types of business objects, like “Product”, “Customer”, etc) so much when it is just a representation of your database row.

If you change a column in your database for whatever database performance reason, and the model class is a serializable one, and then you de-serialize an objec serialized before change. How will you manage that? (I actually had the same exact situation before, with an object serialized to be persisted in Windows Workflow and de-serialized after months where the class changed due to coupling to the DB).

… On General Guidance

Here came some general notes on achieving in software. Software NEEDS to be (just as in those old computer science books):

  • Highly Cohesive
  • Loosely Coupled
  • Hardware Independent
    • Not that it works on PC and Mac :)
    • But that it (as much as possible) works on 1-processor single machine to a farm or cloud of servers with so many logical and physical processors in them.
  • Reliable
  • Performing
    • Concepts have changed here. People now no longer apply a rule like “reflection is too expensive to use in our applications” (and many great things we see today use reflection heavily in their core)
    • Odd enough but works: In many situations, when you have issues with performance, you just put more RAM (Hardware in general) into it until later you fix/re-factor. Hardware is cheaper than programmers.
  • Maintainable
    • This is what today’s designs and patterns focus on most.

In general, software is developed to fulfill certain needs. It need to be architected and planned to fulfill those needs. Software needs to be:

  1. Envisioned
  2. Planned
  3. Executed
  4. Adapted

… On Layering With Recent Architecture

Then Omar went on talking about architecture in a bit weird way. He went through architecture of the future, and afterwards, of today.

Here’s how he sees architecture of the future:

  • Subsequent of the past
    • New Tools, Old Patterns
      • Design patterns have been there for years.
      • The best way to describe Service Oriented Architecture (SOA) is in terms of component oriented design, the same concepts of the old COM+.
      • Service Locator and Dependency Injection are just glorified factory patterns.
  • Destruction of religious discussions
    • Religious Discussions
      • Dynamic Queries vs Stored Procedures
      • C# vs VB
      • Plain ASP.NET vs SharePoint
      • …..
    • As mentioned before, do not special feelings about a certain technology.

To reach this, that’s how an “Architecture of the Present” consists of for Omar:

  • Consumer
    • ASP.NET, WPF, …
      • Note that a WCF service that depends on another service or solution is also a consumer of that
    • Needs to talk to black box that has the engine
      • Knows nothing about implementation, just a contract
      • Normally you should be easily swapping implementations (contents of the black box) while keeping the interface(AKA, the box).
      • Black box is only DLLs, with no tech, not It’s not SharePoint not anything, the only dependency for it is .NET framework.
        • I asked Omar how do you test and mock work that you do in MOSS (SharePoint), he said that it’s usually just dump code that calls WCF services that are actually the front faces of all the real operations.
  • Domain
    • Entities and Services
      • Entities are the model, again, the “Product”, “Customer”, etc. To explain I tell you they do NOT contain anything except their own knowledge. No persistence or such.
      • Service are:
        • Data Services (“UpdateCustomerRecord”)
        • Business Services (“CalculateDailyReport”)
  • Core
    • The very basic entities and interfaces for the services
    • The contracts live here, the implementation goes to the domain.
    • Say this is a VS Class Library Project. Then this will be the only Project that does NOT depend on other Projects in the Solution, and mostly all other Projects will be depending on it.
  • Aspects
    • Cross Cutting Concerns, the things you perform/need for almost every solution
      • Validation
      • Security
      • Logging
    • They should be implemented in a way that provides consistency path. So that developers are not confused when writing it.
    • Omar says those should be injected. We’ll see how next.
  • Only now after defining those, Omar tends to create the database.
  • Then comes the actual service implementation.
    • He uses dependency injection to makes the consumer just calls the domain via the contracts (interfaces) to and then the implementation gets injected.
    • For Aspects, he uses Aspect Oriented Programming (AOP) / Policy Injection to save the developer from writing those for every method / property.

… On Dependency Injection

Dependency is about interface oriented programming:

  • The Core will have its IService interface
  • The domain will have its ServiceImplementation class that implements the interfacen.
  • The consumer will NOT reference the domain directly. It’ll call “something” called Dependency Container that returns an instance of that interface.
  • The container is then configured to return an instance of ServiceImplementation whenever it’s asked for an IService.
  • Normally you wouldn’t have interfaces for entities (just the services).
    • So, you might not have IProduct interface, but most likely you have an IProductRepository (a data service for Product).

Think of contracts for your day-to-day services. Say a Plane Ticket. This is an API, an interface. It has Date, class of food provided, flight no., etc…, but it knows nothing about the exact physical plane that will hold this number, how it works, or the name of its captain, because this is all implementation detail.

This guarantees ease of changing the implementation (say replacing the plane itself). Services need to be designed by the architect. Of course they all reference the core (which holds the contracts), hence you can easily have other service implementations later.Note that the entities implementations are just testable unit/implementations on their own with no special dependency/reference

Again, the cores references nothing,and most other layers reference it. That’s why internal dependencies need to be defined. This is what products like NDepend provide today and what VS 2010 is going to have built-in.

… … The Service Locator

This is just a factory. It’s job is to locate the service implementation (I’d ask you to imagine a GetProductService function with return of type an IProductService as a service locator). That’s how the consumer never talks to the domain. It calls a Service Locator to get a reference to the service without knowing anything about the service except its interface that lives in the core.

There’re two ways the locator can locate and return the desired service. The service type may be written down in some configuration file and it uses reflection or so to get it, or it can perform some other code logic to get the service (which can be as easy as loading some service assembly and getting a specific class from it).

There is no standard for implementing the locators. You may want to provide a singleton object (have a single ProductService and return it every time an IProductService is requested rather than creating a new object for every call). You may want to cache the object for a certain period.So, implementation does differ.

… … The Dependency Injection

What dependency injection adds to implementing a service is:

  • Standard
    • You have a certain library that you call to get the dependency (service). You configure this library for your specific needs.
  • Turns Service Locator into Glorified Smart Factory
    • It can do more functionality, and it has been tried.
  • It can crate an entire chain of objects, not just one.
    • What if you have (and this is not an accurate example or best-to-do) an IOrderService that has one property of type IShippingService, and you want to create the order service and the dependencies of Order service itself. A dependency container library should provide you with a way to define in the same place what order service to use, and what shipping service to use with this specific order service.
  • There’re main libraries for it
    • Castle (Windsor)
    • Structure Map
    • Spring.NET
    • Enterprise Library (Unity)
  • The style is simple, you have a component (any kind of consumer code), it calls a configured dependency container, and this container returns a ready-to-use instance.

To demonstrate this, Omar presented a demo of an IProcessor interface with only a single method: ProcessMessage and a single property SubProcessor of type ISubProcessor, ISubProcessor also has a single method ProcessToConsole. Each of the methods takes a single parameter “”Message” to process.

Now the service factory is easy to create. Using Unity, that’s just a few lines of configuration copied from documentation. The implementation is pretty easy too. Just write the classes Implementation1,Implementation2 that indicate (by simple writing to Console) they were created and called and then pass the message to the sub processors, SubImplementation1, SubImplementation2 that also just indicate they were created and called.

The console program that acts as a consumer was also easy. It has some code like:

IProcessor processor = ServiceFactory.GetProcessor();

processor.ProcessMessage(“The message”);

So, hrere you seethe consumer just talks to the service locator. In the app.config file we tell what implementation to call when asked for IProcessor and when defining that tell it also what to return for ISubPorocessor. To demonstrate, Omar showed calling Implementation1 with SubImplementation2, Implementation2 with SubImplementation2, and even showed that Implementation1 with SubImplementation2 would just work. And run this on the console to see it actually did work.

… On Policy Injection

As mentioned earlier, the policy injection is a pattern that handles cross cutting concerns, the normal things in all projects. Exception Handling, Logging, and Exception Handling would make it for great examples. They’re things shat we shouldn’t be writing code for them everyday!

The way you do this is by using a global handlers that you inject them (say as you do in dependency injection or by putting Attributes on the thing you want to inject into, which is [in OVERLY simplified manner] Aspect Oriented Oriented Programming). Then have then create events that you implement handlers for. Those handlers become the single place to write your policy code (the logging, exception handling, authorization check, etc..).

There are of course frameworks that help you doing this:

  • Castle (Windsor)
  • PostSharp (Code Contracts in .NET 4)
  • Enterprise Library (Policy Injection Block)

The idea of using is similar. The consumer creates object from a factory, then this instance gets a proxy class created around it (similar to the proxy class that gets created when you have a plain old ASMX web service, anyway, it depending on the library and whether it works in runtime or compile time) around the object, and have events in every property/method in that proxy, then others can subscribe to those events later to inject their policies.

To illustrate, Omar presented another demo. He had a Calculator class (that of course implements an ICalculator) with one method SubtractTwo(number) that just does as its name says (subtract 2 from the given parameter), and showed how to use the Enterprise Library Policy Injection to put a logging handler for it that was set in conifg for all objects of type ICalculator. That’s how the policy is applied to all objects from configuration while the consumer got the ICalculator object itself normally by asking a service factory to create it.

So, as per Omar, that’s how you would do it (like other parts in the post, made longer to illustrate more):

  • Configure what implementation to attach for the specified contract
  • Configure what aspects to to have along with entities and services that implement this contract
  • Create the the actual implementation of the attached service
  • Wrap it with the chosen aspects.

Omar also showed another demo. A real life code from a real customer (one of the big customers he has been working with). We saw the –now– normal stuff, the core that references no one (with interfaces, aggregates, and service contracts in it) , the services either business (which We things like SomethingEngine or SomethingManager,…), or data (which were called Repositories – as usual in similar architectures).

… On Summing up

On summing up,Omer emphasized:

  • Do not code logging (and such) over and over again
  • Watch for performance, moderately
  • Go for standards
    • Use Standard Frameworks, not no name ones (DISCLAIMER, that’s Omer speaking).
    • Standardize your own frameworks.

I have the feeling that I didn’t include everything here, especially some side talks that were worth noting (some are noted). It was a great session with some discussions that are rarely there except in very small groups. Again, I really want to bring similar discussions, either as a speaker or an attendee.

Then came the open sesion …

Well, This one was an open session. I haven’t seen a “bad” open session in Egypt, but also never saw one that would meet my standards for “Successful”, “effective” or such …

There wasn’t much audience this time (Which is really funny and always happened! Seeing that a vast majority of the attendees are students, when the sessions are prepared to meet this level, the audience that attends happens to include many high rank developers. As you may have guessed, when the sessions are prepared to meet this advanced level …. Yeah, only the junior ones are there. This is another post on its own!).

This time the audience was ready for the session but much fewer than it should have. The open talk session didn’t have much talk then more than a demo that shows Tech ED domo on how to use the MS Reporting Services 2008 Report Viewer to create a report from scratch, publish it to your server, and export it to MS Word n less than 5 minutes. Not something that would impress me personally when it has the “less than 5 minutes” in it and Omar himself said a simple report in reality would take around half an hour to design.

The other talks were all like “”What do you think about using the X… technology in Y…. situations”. It was limited to one-hour session anyway due to accidently tight buses seclude.

Some things that are good for example are mentioning the models of doing software in/outside the cloud (topic brought by Mohamed Samy).Omar said those are the common themes:

  • I build software and build data
  • The two at Microsoft (or whatever provider)
  • Data is here but the software is by another provider
  • Data by vendor and he’s liable to it
    • By looking at the terms and statements of Windows Azure, Omar says he found nothing that expresses liability from Microsoft’s side.

Also, when someone asked him whether to use WPF or Win Forms for desktop “Business” applications. He said he uses WPF for all his applications, for business applications he has a WPF theme that looks just like Win Forms. He explains why he does it this way:

  • WPF works directly on the GPU.
  • XAML is a great language, same like HTML but without all the browsers headache and even better syntax.
  • Basically a business application does not have complex UI requirements, but, if some are requested, a WPF application is ready.

He also mentioned the best way to learn .NET is to open reflector, browse the namespaces and see the code for anything whose name grabs your attention. An example is how Serializable attribute is implemented, it’s just an enum :). another example is how to implement an Object Pool. So that for example whenever an object is requested, no more than say 5 instances are created and reused in later requests. Before you think about the implementation, it’s just there in the BCL,in System.EnterpriseServices.ObjectPool. Just have an ObjectPool with Max set to 5 and you are done with it :) :).

It was a really great day. Thanks a lot, Omar.


Share With Friends:

How did I learn that?

As a bonus for coming here, I'm giving away a free newsletter for web developers that you can sign up for from here.

It's not an anything-and-everything link list. It's thoughtfully collected picks of articles and tools, that focus on Angular 2+, ASP.NET (4.x/MVC5 and Core), and other fullstack developer goodies.

Take it for a test ride, and you may unsubscribe any time.

You might also want to support me by checking these out [Thanks]: