Devolución de datos de la base de datos en .net: ¿Devuelve una tabla de datos o LIst <T>?

Question

Estoy luchando por unir los conceptos de un buen diseño de base de datos con un buen diseño orientado a objetos.

Tradicionalmente si quería ver una lista de las noticias en un repetidor, me gustaría utilizar algo como:

<script runat="server"> 

    void ShowNews() 
    { 
     rptNewsStories.DataSource = News.GetAllNews(); // Returns a DataTable 
     rptNewsStories.DataBind(); 
    } 

</script> 

<asp:Repeater id="rptNewsStories" runat="server"> 
    <ItemTemplate> 
     <div> 
      <span class="Title"><%# Eval("Title")"%> (<%# Eval("Location")"%>)</span> 
      <p> 
       <%# Eval("Summary")"%> 
      </p> 
      <ul> 
       <li>Added by: <%# Eval("AddedByFullName")%></li> 
       <li>Added on: <%# Eval("AddedOn")%></li> 
      </ul> 
     </div> 
    </ItemTemplate> 
</asp:Repeater> 

Aquí News.GetAllNews() devuelve unDataTable, que es sólo una volcado de lo que devuelve el procedimiento almacenado. El procedimiento almacenado se escribe para devolver datos mediante el uso de combinaciones, por lo que hay más de una tabla de datos valiosos.

La ventaja de esto en que, en la base de datos del procedimiento almacenado puede averiguar quien añadió la noticia de la AddedByID que existe en las noticias mesa y devolver las personas nombre completo como el valor AddedByFullName devuelto .

Sin embargo si intento y soltar el uso de un DataTable y en lugar de devolver una lista de los objetos de noticias, me sale el siguiente:

<script runat="server"> 

    void ShowNews() 
    { 
     rptNewsStories.DataSource = News.GetAllNews(); // Returns a List<News> 
     rptNewsStories.DataBind(); 
    } 

</script> 

<asp:Repeater id="rptNewsStories" runat="server"> 
    <ItemTemplate> 
     <div> 
      <span class="Title"><%# Eval("Title")"%> (<%# Eval("Location")"%>)</span> 
      <p> 
       <%# Eval("Summary")"%> 
      </p> 
      <ul> 
       <li>Added by: <!-- Here there is only a AddedByUserID, not an AddedByFullName value --></li> 
       <li>Added on: <%# Eval("AddedOn")%></li> 
      </ul> 
     </div> 
    </ItemTemplate> 
</asp:Repeater> 

Pero ahora me quedo con el problema de que ciertos valores que Quiero mostrar (Como AddedByFullName) no existen dentro del objeto Noticias, porque no son algo que está explícitamente establecido, sino que se recuperan de un ID de búsqueda en el objeto.

Me gustaría devolver objetos en lugar de DataTables, pero no sé la mejor manera de cerrar esta brecha.

Do I:
* Crear propiedades adicionales en las Noticias clase para cada valor adicional que se puede devolver a la base de datos en relación con estos datos?
* ¿Quédate con DataTables para casos específicos donde hay muchos valores adicionales?

¿O simplemente estoy en el camino equivocado?

Answer 1

Sus opciones están restringidas por la tecnología subyacente que está dispuesto para su uso como acceso a datos. Por el momento hay varias alternativas que el conjunto de herramientas de VS y .NET Framework son compatibles:

• Classic ADO.Net 2.0. Diseño en Typed datasets y DataTable objetos en el código.
• LINQ to SQL. Diseñe en LINQ O/R Design modeler, use IQueryable<T> y la sintaxis de LINQ en el código.
• Entity Framework. Diseñe en el Entity Data modeler, use entidades en su código.
• 3ª herramientas ORM partido como NHibernate. Cada uno tiene su propio diseñador específico y tipo de objeto de código.

A partir de estos, todos los conjuntos de datos, excepto ADO.Net, le permiten especificar las relaciones de navegación como usted lo hace, ya sea con ansiedad o con poca carga. En un caso como el que describes, la clave natural para estas tecnologías sería modelar explícitamente la relación entre el artículo de Noticias y el autor en los diseñadores y dejar que el marco aborde el problema de cargar los datos apropiados y los tipos apropiados, lo que en última instancia significa que el problema de unión se maneja implícitamente por la capa de acceso a los datos de la aplicación (el marco) y no por un procedimiento almacenado creado explícitamente.

La elección de la tecnología fluctuará en todas partes en su código, desde cómo obtiene sus datos hasta cómo lo visualiza y cómo actualiza, ninguna de estas tecnologías es fácilmente intercambiable. Personalmente, encuentro que el equilibrio correcto de potencia y complejidad es con LINQ to SQL.

Answer 2

Buena pregunta:

Hay un par de enfoques que puede tomar:

1. Puede recuperar los datos adicionales que necesita en el proceso de unión del repetidor y rellenarla en un " marcador de posición "para cada registro de noticias devuelto. Esto tiene problemas de rendimiento debido a las consultas adicionales, pero funcionará.

2. De ser posible, modificaría el objeto de noticias para que contenga la información adicional, o crearé un objeto que herede del objeto de noticias que tenía la información adicional o las propiedades contenidas en él.

Esperanza esto ayuda :-) 1

Editar/Comentario: creo que la fricción que está viendo en su diseño es que no se está reconociendo el "-tiene una" relación entre su objeto de noticias y lo que yo llamaría su autor/colaborador.La unión que estás haciendo en tu consulta simplemente oculta la falta de relación en el modelo de objetos.

Answer 3

usted puede probar esto, tal vez no sea la mejor solución:

void ShowNews() 
{ 
    User[] usersConcerned = News.GetAllUsersLinkedWithNews(); //only return the users concerned by the news 
    List<News> news = News.GetAllNews(); 
    foreach(News item in news) 
    { 
     item.AddedByUser = usersConcerned.FirstOrDefault(u=>u.Id == item.AddedByUserID); 
    } 
    rptNewsStories.DataSource = news ; 
    rptNewsStories.DataBind(); 
}