Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts

Thursday, February 04, 2010

Thursday, January 14, 2010

Graphs : Relational database versus Graph database

Check the following articles on how to represent graphs in both a relational database and graph database:

 

Graphs in the database: SQL meets social networks

http://techportal.ibuildings.com/2009/09/07/graphs-in-the-database-sql-meets-social-networks/

Social networks in the database: using a graph database

http://blog.neo4j.org/2009/09/social-networks-in-database-using-graph.html

Tuesday, January 05, 2010

IBM software architect kit

Get yourself a wealth of architecture resources in the following kit from IBM:

https://www6.software.ibm.com/developerworks/offers/kits/archkit1/index.html

Wednesday, December 30, 2009

MySpace.com uses iBATIS.NET for persistence

iBATIS.NET the .net port of the iBATIS Java ORM is being used by MySpace.com http://www.infoq.com/news/2006/11/iBATIS-MySpace

Saturday, March 22, 2008

Auto-wiring an MVC Triad using Unity

I think this post's title is a little bit cryptic, but if you did understood my intentions; you are possibly an IoC geek and may be you know what I am trying to say here.

So, let me explain the phrase from right to left:

Unity: The Unity Application Block (Unity) is a lightweight, extensible dependency injection container with support for constructor, property, and method call injection; it will be part of Entrprise Library version 4.0 and it has its own space on codeplex (www.codeplex.com/unity )

MVC : The famous Model-View-Controller design pattern used in the presentation layer since its invention in the 70s.

Wiring: The MVC pattern requires 3 classes to exist and coordinate together, the Controller class will need an instance of the Model and View, and the View will need a reference to the Model so it can handle the display of the Model.

In the normal life of any MVC based application, we will need some code like this:

Model m = new Model();

View v = new View();

Controller c = new Controller ( m , v);

c.Start();

By this; I mean wiring the classes together so they will be able to communicate.

Auto-Wiring: Is the mechanism of automatically wiring the classes together without the need to write the above code again and again.

One of the auto-wiring techniques is to use the Dependency Injection pattern, and instead of building my own implementation of it, I am using the Unit Application Block.

Unity is able to discover the dependency of the classes based on their constructors, so in the above example; Unity will discover that Controller will need a Model and a View instance so the Controller can be instantiated, and also the same for the View.

Using Unity, all what is needed is to call the Resolve method in the UnityContainer and it will instantiate all the dependencies for us (namely the Model and the View), and will instantiate the controller and pass it the created instances auto-magically.

UnityContainer container = new UnityContainer();

Controller c = container.Resolve<Controller>();

c.Start();


I have made a sample application, you can check to see the above code into action. You will need VS2008,no need to download or setup Unity, since its assemblies are included.



Agree, Disagree? I like to hear your comments.


Friday, February 08, 2008

[Architecting Desktop Applications with 2.0] MSDN Webcast series

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 01 of 15): Smart Clients and N-tier Design (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 02 of 15): Design Patterns for GUI Applications (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 03 of 15): Creating Dynamic and Configurable Applications (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 04 of 15): Architecting a Secure Desktop Application (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 05 of 15): Designing the Business Tier (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 06 of 15): Designing the Data Access Tier (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 07 of 15): Best Practices for Developing N-Tier Applications (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 08 of 15): Turning Tiers into Components (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 09 of 15): Build, Build, Build, Test, Test, Test (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 10 of 15): Multithreading for Performance and Responsiveness (Level 300) (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 11 of 15): Designing Distributed Applications Around Remote Access (Level 300) (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 12 of 15): Designing Distributed Applications Around Web Services (Level 300) (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 13 of 15): Securing a Distributed Application (Level 300) (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 14 of 15): ClickOnce Deployment (Level 300) (Level 300)

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 15 of 15): Learning from Agile Development (Level 300) (Level 300)