Barrapunto

Muchas gracias por tu apoyo, y buena previsión con los trolls, ya he visto alguno por ahí ;)

El patrón Scope nos ha resultado muy útil a la hora de hacer el código más simple y legible. Si te interesa hay más cosas parecidas en Signum.Utilities: Sync [signumframework.com], CSV [signumframework.com], DirectedGraph [signumframework.com]

Tus preguntas:

• Queríamos mantenernos flexibles para hacer cambios el código si lo consideráramos necesario, y tener la documentación en varios idiomas hace eso más complicado. Elegimos inglés por la audiencia. Posiblemente este verano comencemos a traducir al español la documentación. Evidentemente el código seguirá en ingles.
• La decisión de usar Lazy ha sido difícil, pero creo que acertada. La principal diferencia con otros motores es que nuestras entidades están diseñadas para ser serializadas y enviadas a un cliente desconectado de la base de datos, en ese escenario necesitas saber qué cosas tienes disponibles y cuáles no. Lazy es aplicable también en otras situaciones, como en queries Linq o para pasarlos como parámetro.
  Además, permite tener un control explícito sobre cuando está habiendo comunicación con la BBDD, o la identidad de los objetos (ObjectCache).
  Los EntityControls saben tratar con Lazy de manera transparente asi que realmente sólo genera un pequeño estorbo cuando estás escribiendo lógica de negocio personalizada (poco a menudo) y en ese caso sólo tienes que hacer '.Retrieve()' sobre el Lazy y ya tienes la entidad.
  
• No conocía el problema por ese nombre. Imagino que te refieres a http://www.pbell.com/index.cfm/2006/9/17/Understan ding-the-n1-query-problem [pbell.com]. Nuestro proveedor de LINQ es bastante potente, una query como la expresada en ese link podría expresarse fácilmente así:
  

  from c in Dabase.Query<ProductDN>()
  group c by c.Category into g
  select new<br>
  {
  CategoryTitle = g.Key.Title,
  ProductCount = g.Count()
  }

  Y sería traducida a una sola query, siendo bastante eficiente. En general la mayoría de las consultas que devuelven una sola tabla de datos se pueden hacer de esta manera, generando 1 sola query SQL.
  Cuando lo que se necesitan son datos jerarquizados (maestro detalle por ejemplo) entonces sí que aparecería el problema de las N+1 queryes (aunque sería completamente transparente al programador).
  En un futuro nos gustaría quitar este problema también, si quieres ver algo duro, Matt Warren enseña cómo hacerlo en este post:
  http://blogs.msdn.com/mattwar/archive/2008/11/17/b uilding-a-linq-iqueryable-provider-part-xii.aspx [msdn.com]
  En cualquier caso, no habría ningún cambio que hacer por el programdor final, cuando haya mejorado eso el código simplemente irá más rápido :)
  
• Vamos a tirar de ASP.Net MVC por ahora, utilizando llamadas AJAX para la validación y alguna cosa chula más. El objetivo es conseguir una experiencia de programación similar a la que tenemos con Signum.Windows.
  El problema con Silverlight es que no puedes compartir las entidades entre el cliente y el servidor, puesto que el cliente utilizaría el runtime silverlight y el servidor el Framework completo.
  Existen algunas ñapas posibles (como usar 'Add Link' en diferentes proyectos