Arjen Poutsma has been added to our list and I've finally fixed the links (Dennis, thanks for the reminder). Grab the OPML file here which contains allot of Dutch .Net developers. Are you a Dutch .Net developer and want your name on our list, drop a line email@example.com
Rocky Lhotka proposes a transformation of the traditional “data layer” (one that serves a database that is shared amongst applications) into a service. And thus, according to Rocky, simplifying the application layering. Sounds great right?
Instead of the following typical layers:
1. User or other consumer
2. Presentation technology
3. UI logic
4. Business logic
5. Data access logic
6. Data source
We now only have:
1. External interfaces
2. Business logic
And one or more external interfaces:
1. Data access
2. Service agents
3. HTML interfaces (to interact with web users)
4. GUI interfaces
Thus far we’ve only moved from a typical integration style namely “Shared Database” to “Messaging” [EIP 2004]. Honestly, the difficulty of this new architectural model as Rocky describes it, doesn’t lie in setting up the thrust boundaries.
In my current project we are using (this new architectural model) a serviced “data layer” approach, where multiple applications interact with this service called Dustbin. I’m currently working on one of the external interfaces in which we exchange messages with Dustbin, execute business logic, coordinate workflow through (Biztalk) and communicate a friendly UI to our end users.
I think the challenge in this architecture is to share the same language (canonical data model) between these applications. This additional level of indirection provides a way to overcome the individual data formats of these applications. This is where good designers come to play and eventually come up with the first step to resolve dissonance.
Be warned… at the end of the day you’ll find yourself interfacing the database (in a RPC based style using Web Services) with no or less added value. The importance to make this “new architecture model” successful lies in the design of a robust Canonical Data Model. So saddle up skilled designers ;)
I have just spent an hour or so reading through an article about which .NET ORM is best. Decide for yourself. All I'd like to add is... there's no silver bullet and only a handfull of the stated products are production ready.