Random Metaphors

notes on access control

2009-10-27T20:17:00.000-07:00

access control is usually an application concern -- think current user.

if access control is done in the domain, the it should be part of the domain language, not calls to security check.
e.g.
Role.Approves(request) <- the security is built into the language here
Boss.EntersExecutiveBathroom(urgency) <- again, built into the language.

Thinking about using permissions immediately pushes into application concern and does not belong in the domain.
if (user.hasPermision(permission)) <- this sort of stuff

see http://tech.groups.yahoo.com/group/domaindrivendesign/message/15484

Application rules set a sort context for the domain to work in. Moving domain to a different application might lose some rules because they only made sense/were defined in that one application/context.

In the domain, do not talk about "the current user". Talk explicitly of the roles and what the roles can do.

Thoughs on how to refactor an ugly ActiveRecord into something more flexible.

2009-10-24T08:30:00.000-07:00

Separate command and query in your domain layer.

Command Accepting entities should not have public state.

Command Accepting entities probably have a bunch of overloads to Accept() with the parameter being the type.

Might be a good idea to have a domain event aggregator. This is like an internal message bus. There are several good articles out there about how to build one. Udi has one that I've used.

So, when a Command-Entity accepts a command it should publish internal state changes as events to the event aggregator. You can then take care of different concerns in different event handlers. Concerns might be:

Bring the eventually consistent reporting and/or query stores up to date.

The event logger should capture this too if you are using event streaming. Somehow this has to be fail-proof. Not sure how to ensure this yet. If it fails, issue compensating command? Logger has first chance to process and if fails, don't allow events to be publish?

Probably a good idea to make commands idempotent. If you are using a distributed system timestamps on the commands aren't very good. Guid probably can only help if you keep a blacklist of already process commands. This sort of has risks in multi-threaded scenarios. I saw Ayende comment about this. Another good technique is to ensure commands are handled serially and compare a version number.

Still haven't found any good examples of how to deal with large event stream stores. The DBA on a project is recommending Oracle indexed table with advanced compression using Oracle Xml DB. Maybe using a GUID-comb for the entity id.

A command accept method might look like:

Acquire lock. Unless you are sure this command wont step on the currently executing one.

ValidationEngine.Validate(command, entityDTO)

I guess ValidationEngine would be a domain service injected into the Entity. Some folks say this is bad at all costs. Some say domain services are ok just don't inject infrastructure services. I'd love to see some real world examples of how to determine which is which. In that case the command handler is external to the entity. This makes it infrastructure. So then you can inject query services to get the DTO and use a ValidationService in combination with command and DTO data.

PerformComputation(command)

PublishStateChanges() and other events if necessary.

Release lock if necessary

The command distributor would be responsible for logging the command. Also ensuring security concerns. Guess security is an infrastructure concern?

Not all business rules are handled inside the domain. Things like ensuring uniqueness of a given key is handled the simplest way closest to set itself. If using a SQL database, use a unique key constraint on the on the reporting/query store. If this fails, issue a compensating command. This sounds fine and all about what about the usable state of the entity in between that time? What about other listeners of the event? How do they get compensation? I suppose entity version in commands would prevent any old query derived commands from executing but what if the query store succeeds but the event logs fails? That could allow version OK commands, that really should get processed but timing could allow it. Can the event log talk to the query store? Maybe answered above.

Projects list

2009-09-18T05:45:00.000-07:00

Automapper
blueprint-css
Fluent Validator
Json.NET
Linfu
Migrator.NET
NBehave
NServiceBus_2
Rhino Mocks 3.6
RikMigrations
Run-Sharp
StructureMap 2.5.4
Topshelf
xVal
Machine for mSpec and Migrations

again, turn it inside out, SRP

2009-08-09T14:45:00.000-07:00

So you don't want infrastructure leaking into your domain model.
Make another class that encapsulates your domain with a reference and then
has all the infrastructure details. The repository will have a list of these
wrappers instead of just a list of the domain models.

Ambiguous Action handlers in ASP.Net MVC

2009-07-08T15:10:00.000-07:00

The RESTful URLs present a little bit of a challenge to the ASP.Net MVC framework. The example I had is where I want to post various different forms to the same URL. What I would like to do is take advantage of the automatic model mapping that having a form in the argument list for action method. At this point, out of the box you will get an ambiguous action error message since you have two method with the same name, just different argument lists. The reason for the same name is the Simply RESTful routing handler uses a standard set of possible actions. In the post case, you must have an action named Create.

There is something you can do about this. In the answer to MVC Ambigous action methods an action attribute is coded and derived from ActionMethodSelectorAttribute. This has a method IsValidForRequest which seems to be called by the framework when figuring which action method to invoke. So I modified this a bit, knowing that all my forms will have different prefixed, if a Param key has that prefix I know use that method.

so in a controller I have


  [RequireFormPrefix("z")]
  public ActionResult Shmoo(Model1 z)
  {
      return View("Shmoo1", z);
  }

  [RequireFormPrefix("q")]
  public ActionResult Shmoo(Model2 q)
  {

      return View("Shmoo2", q);
  }

and


public class RequireFormPrefixAttribute : ActionMethodSelectorAttribute
{
  public RequireFormPrefixAttribute(string formPrefix)
  {
      FormPrefix = formPrefix;
  }
  public override bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo)
  {
      // holy moly this is a law of demeter violation
      foreach(var key in controllerContext.HttpContext.Request.Params.Keys)
      {
          if (key.ToString().StartsWith(FormPrefix + "."))
          return true;
      }
      return false;
  }

  public string FormPrefix { get; private set; }
}

Easier to find or remember

2009-06-21T14:35:00.000-07:00

Object Oriented principles and practices

SOLID
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation
- Dependency Inversion

Law of Demeter

DRY - don't repeat yourself

YAGNI - you ain't gonna need it

Reminder notes on some object types/

2009-06-21T14:25:00.000-07:00

Just something I want to remember without having to do a web search.

DTO = data transfer object
VO = value object or transfer object.

Two main differences between DTOs and VOs.
First is mutability. DTOs are mutable property bags and VOs are immutable.

The second difference between DTOs and VOs is how equality is determined. DTOs are based on object identity and value objects are based on state. I think this means to say that if you override the Equals() on a DTO that computes on state data you have successfully converted a DTO into a VO. Another rephrase is that you must override the Equals() on a VO.

Got this from http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/

RESTful Searching

2008-08-05T14:43:00.000-07:00

Digging into the wild world of REST where there seems to be a lot of information and conventions, I also find there is a lot lacking. I did notice on another blog, wish I kept the reference, that there are a lot of things REST experts would agree on but really no repository of "better practices".

The rails conventions make it very easy to publish entities and do repository style filtering of all the entities of a known type. This is typically done by a GET to a resource URI and most likely with query parameters. This URI GET is usually mapped to a controller's index method. I have some interesting question regarding caching that I think are satisfied using the VARY Http header. Consider that the authorization cookie is actually part of the filter criteria. Meaning results could vary depending on who is doing the searching. Alas, I digress.

My biggest problem so far is what happens if there are user modifiable properties of each search result. Say, there is a check box on each row for a multiple choice scenario. We can't use a GET to modify a resource as its against the idempotency law. Well, we could put this property on the backing entity. Then we have to figure out what to do if multiple people are searching and toggling this selection. Clicking this box would then POST to the backing entity URI. Thing is, how would the controller for the resource POST know to redirect back to the exact search URI? I'm sure people really don't want to tack on a redirect property. I don't particularly like this one.

Perhaps, the result in the set of results is its own entity. Efficiency nerds would cringe at keeping copies of data in multiple forms, especially for multiple users and then perhaps even multiple times for the same user. Ok, so we don't expose each result per se but rather, allow a POST to the search URI where it can maintain state of all the selected results (one way would be to have a form with all the chosen ids in a hidden inputs along with a choose link which submits them. But to where?) I've seen that when others have stumbled into the problem where a search combines heterogeneous entities, they seem to go for a separate search URI as well.

Anyhow, I think I will experiment with this approach and see how it goes.
Expose the resource URI as

/ResourceCollection

POST[Create new]
GET[non-filterable list, page-able? OK]

/ResourceCollection/ID

GET[get it]
POST[not defined]
PUT[Update]
DELETE[kill it]

/ResourceCollection/New

GET[returns a form that represents the entity and will POST to /ResourceCollection]

/ResourceCollection/ID/EDIT

GET[return form for editing that PUTs to /ResourceCollection/ID]

/ResourceCollection/ID/DELETE

GET[return form for confirming delete, it DELETE to /ResourceCollection/ID]

Then for search have the following scheme

/ResourceSearch

POST[create new search results, redirects to /ResourceSearch/ID]

/ResourceSearch/New

GET[form to create new search results]

/ResourceSearch/ID This resource should/will be security context sensitive. Only the user who created it should be able to work with it.

GET[typically with query parameters for paging and sorting].
POST[updates something about search results, accept post entity of only a search result or perhaps a property of a search result]

This seems like a bit more work but perhaps more flexible. Is it all still RESTful? I think so. Now, what to do with all these sets of search results?!

Then again, maybe there is a better metaphor to solve this problem than sticking a checkbox on a result row. Create a selected resource which is just a maintained list of result rows? Your search results view would then possibly show this list along with the paged results from search? The list of search results would have buttons to add to the selected list?

I'm also coming at this from non-Ajax perspective. In an Ajax world, the client could maintain the list of selected items.

The experiment will be implemented in the ASP.Net MVC framework and using the provided SimplyRestful routing.

First Post

2008-01-02T10:19:00.000-08:00

Welcome, this is just a test post.