This past Saturday, Tim and I hit the links and talked "shop" for a while. I was like talking "shop" with Tim because he always has some good inputs/insights on design, architecture and beer. One of the topics we talked about for quite some time was that of domain objects. The conversation went a little like this ...

  • Tim - So, do you have any business logic in your objects?
  • Me - No, I see domain objects as nothing more than just complex types. The are but puppets of my(1) framework.
  • Tim - Then how do you get your objects?
  • Me - My persistance layer.
  • Tim - So you let your domain layer have knowledge of your data layer?
  • Me - No, I have my persistence layer have some knowledge of my data layer and some knowledge of my domain layer. It's like a glorified proxy.
  • Tim - Wouldn't the fact that you need to call your persistence layer from your UI (View) layer, confuse your UI developers?
  • Me - Aaaahhh, no. My UI (View) layer doesn't call my persistance layer, my sub-controller does.
  • Tim - What's your sub-controller?
  • Me - The code-behind of my ASP.NET application or Windows Form.

To me the code-behind of an ASP.NET webform|user control|web control is not the UI layer because it's not something the end user directly sees. To me it's the state machine that performs action X when button Y is clicked|moved|goosed. The UI layer is the HTML and ASP.NET control tag library that is used to depict the layout of the page. Remember that code-behind (sub-controller) can alter can be rendered iff the UI component is designated to run on the server.

Having explained all basis for my madness, here's a diagram of what component interaction under ASP.NET might look like:

Component Interaction

Here's a quick description for each of the components:

  • Controller - Receives the requests and decides what type of sub controller is best suited to handle the request. Interaction: Sub-Controller
  • Sub-Controller - Delegates which persistence services to call and is knowledgeable of the binding of domain objects. Interaction: Persistance, Domain & View
  • Persistence - Contains business logic used to interact with a domain object. It is knowledgeable of both provider(s) and domain components. Interaction: Domain & Provider
  • Provider - Contains the information for communicating with data store and typed data entity items. Interaction: Provider Helper
  • Provider Helper - Executes command against data store using typed data entities. Interaction: Data Store

There will be more to come on each of these components in later posts. Perhaps with these posts, you can get a glimpse on how my mind thinks from time to time.