Generic Strategy Pattern

Published 11 January 06 12:21 PM | adrian

When asked about what is the most important feature in .NET 2.0, I'll say: Generics! This feature does a lot of job now and a lot more in the future technologies (LINQ, etc.).

I was in a project, coded using VS 2005 Beta 2, so there are Generics there, also bugs. A day before deadline, I asked myself whether porting the code to 1.1 is better. The questions stopped when I realize that when moving back to 1.1, I'll have to change all those Generics to old-school inheritances... That's a no-go.

So, when working on a running project (due late January, will be released on freeware license), I've found out that those old ORM codes using Strategy Pattern is obsolete. I've created a new, more flexible approach using Generics and Strategy, and it's called Generic Strategy Pattern. Here is an example of the actual code:

Public Interface IDataAccessProvider(Of [Object])

  Event ObjectChanged(ByVal e As Collection(Of [Object]))

  Function [Get]() As Collection(Of [Object])

  Function [Get](ByVal id As Guid) As [Object]

  Sub Add(ByVal O As [Object])

  Sub Update(ByVal O As [Object])

  Sub Delete(ByVal id As Guid)

End Interface

This code highlights a basic ORM logic. The implementing class should define what Object (from the O part of the ORM) is to be mapped to relational form. Furthermore, by parameterizing the Object part I've been able to provide a flexible approach to the old Data Access Layer classes. Using this Interface, you can define a mapping for specific Object (well, Class) to specific Relational form. Afterwards, you will need to create a Class that contains an implementation of IDataAccessProvider for all Object that you need to be mapped. For example, I have two Objects (Classes), Foo and Bar. And I have two database implementation, SQLServer and XML. Using IDataAccessProvider, I have created 4 implementations, that is Foo-SQL, Foo-XML, Bar-SQL, and Bar-XML. The final step is compositing those implementations. I can use a data access layer where Foo is stored in a SQL Server database and Bar is stored in XML file, without the need of declaring another Interface. Helps a lot! Please contact me for a code sample. Those codes are not for public use (yet!).

Share this post: | | | |
Filed under:

Comments

# adrian said on January 11, 2006 08:38 PM:

Dude, that's the common way in using Generics, where you can parameterized types.

What's more interesting to share is whether you use code generations or reflection.

# adrian said on January 11, 2006 08:50 PM:

Yes, that's why it is called "pattern". :D

Anyway, the great thing is, client code does not need to know anything about what database implementation (or any combination of it). Jadi client hanya perlu call Interface yang sesuai dengan tipe Objectnya. The rest is handed down... Very useful when you need to implement partial persistence database (one SQL and one XML for example).

# adrian said on January 11, 2006 09:51 PM:

I mean, you can go further describe whether you use code generation or reflection approach...

And then you can describe where you put the metadata (RDBMS or XML info) of each domain type... is it internal (like Attribute) or external (like XML file)...

Lazy load, concurrency, etc to follow...

'Cos what you post here is so... so-so... :)

Come on, an Adrian G gotta be more than this!

# adrian said on January 11, 2006 10:31 PM:

He said that the code is not for public purpose.. hehe..
Well, I think code generator will be the most helpfull tool on ORM implementation. Whether we use it from 3rd party tools (CodeSmith etc) or install it in VS.NET (2003) using Custom Tools on File Properties (like default VS generator on typed dataset).

# adrian said on January 11, 2006 11:32 PM:

:)

Yeah... not for public he said (yet!).

I'm interested to 'see' more as I think the Generics implementation is just 'half of the story'. The other half... (see my previous comment), that's the one that interesting that will show the difference...

# adrian said on January 12, 2006 12:48 AM:

Norman: dunno... blm sampe situ tuh... :D Soalnya memang ini sangat membantu untuk coding manual (belum sampai level code generator atau reflection), karena memang target utama untuk simplify user (client code), lalu kedua untuk membantu compositing di level data access.

Should be extensible, though.