EF4 + ESQL for not supported options

So say you want to support wildcard searches against a SQL db. Yes this is probably horrible performance wise, but... useful or as an example how to do ESQL against an EF4 context.

Linqpad against my EF4 context:

  internal IEnumerable<IPlayerFull> SearchForPlayer(string playerNameLike, byte? universeId)

        {

var q= from p in q.Players.Where(p => p.UniverseId == universeId) 
.Where("it.Name like @Name", new ObjectParameter[] { new ObjectParameter("Name", playerNameLike) })
.Where(p => p.UniverseId == universeId)
       orderby p.Name
      select p;
 return q;

bizarre eh? EF4 note, not related to ESQL:

Class organization

I am putting together a theory of  class code readability organization with the assertions that

• Classes consistently organized are easier to read and understand
• Fields should be private
• Consistent internal state is preferable to passing around invalid objects that can communicate they are invalid (immutability vs IDataErrorInfo)

This layout is my hypothesis of what a good consistent layout would be:

1. private fields
2. constructor(s)
3. Initializers and wiring
1. for example event wiring
4. non-public properties
5. public operations
6. public properties
7. explicit event plumbing
1. For example designer auto-generated event handlers
8. Other plumbing or utilities

As with any theory or concept, the main ways to learn from it are 

• to communicate it out for feedback 
• other people's viewpoints can help you find your blind spots
• you can become aware of situations where the idea or solution doesn't fit and why
• apply it
• look at it with a critical eye for places or reasons that it works well and places it doesn't
• keep an open mind that one size does not fit all
• solicit feedback for applications of the idea
• other people can better see past your blind spots
• explaining it helps keep or find perspective
• any critical thinking or discussion is likely to be beneficial to all involved parties