DAL futuros de prueba

Question

Estamos en el comienzo de un proyecto de desarrollo muy largo con varios subproyectos. Básicamente, cada subproyecto tardará varios meses en desarrollarse. El código en sí se dividirá en varios proyectos C#, pero la base de datos física será compartida por todos los proyectos.

El problema es la capacidad de mantenimiento. Si agregamos una columna a una tabla, o dividimos una tabla en dos tablas más pequeñas, tendremos que retroceder y modificar nuestro C# DAL para respaldar estos cambios. Esto no es aceptable, ya que constantemente adaptaremos el DB a las necesidades de la empresa como un todo, y no solo a las necesidades de un solo programa. Cambiar constantemente el código antiguo sería una tarea interminable.

Nuestra gente de DB sugirió una vista diferente. Hacemos todo nuestro CRUD a través de procedimientos almacenados, y usamos Linq en varias tablas para realizar nuestras declaraciones SELECT. Entonces, si reestructuramos el DB dentro de varios años, podemos simplemente suministrar los mismos procs y vistas almacenados y no tener que modificar nuestro código anterior.

La pregunta que tenemos, ¿qué ORM se debe utilizar para algo como esto? EF parece un poco exagerado (tal vez no lo es). ¿Algo así como SubSonic con su plantilla T4 permitirá un DAL simpliler (y quizás más rápido)?

¿O quizás alguien tiene una idea sobre cómo hacer que todo este proceso sea menos doloroso? Preferimos no agregar otra capa a nuestra aplicación, pero tampoco queremos volver atrás y modificar el código cada vez que hacemos un cambio de db.

Edit 1: Así que cuando dije "realmente no quiero agregar más capas". Esto es principalmente porque ya tenemos varias capas. Tenemos vistas de Silverlight, modelos de vista, objetos BLL (a través de CSLA), luego tenemos el DAL y, finalmente, las tablas SQL que se muestran a continuación.

Answer 1

C# DAL... not just the needs of a single program.El objetivo de un C# DAL como un ensamblaje separado es que se puede reutilizar en cualquier tipo de aplicación .NET. El principal problema que encontrará es que si la base de datos cambia, entonces el DAL debe cambiar (una vez), entonces todas las aplicaciones que dependen del DAL deben volver a desplegarse con el nuevo DAL. También tiene el problema de que DAL no puede ser utilizado por aplicaciones que no sean .NET.

Bien, entonces, ¿cómo puede centralizar el DAL para que no tenga que volver a implementarlo para cada aplicación? Piensa en SOA. Puede construir un servicio WCF para contener el DAL (y probablemente BLL). Todas sus aplicaciones (si usa servicios web, incluso aquellos que no son .NET) pueden usar este servicio. Cuando la base de datos cambia, actualiza su servicio WCF y lo implementa una vez. ¡Solo asegúrate de no hacer ningún cambio brusco! Cree un MyMethod2 si necesita agregar/cambiar la funcionalidad.

Nota: Cuando se escucha de n niveles, por lo general se refiere a tres niveles, donde cada nivel es un software independiente y por lo general en servidores separados: Presentación (IU), aplicación (su BLL/DAL), datos (su base de datos SQL ). Hay mérito en esta arquitectura.

We'd rather not add another layer to our application. Ok, entonces tres niveles puede no ser el mejor enfoque en tu caso.

neither do we want to go back and modify code everytime we make a db change Entonces, lo que su personal de DBA sugirió es la única manera.

Sin embargo, considere esto: ¿cambiar un procedimiento almacenado es lo mismo que modificar el código? Básicamente es lo mismo. Los procedimientos almacenados de SQL a menudo no son controlados o controlados por la versión, pero deberían serlo. SQL no tiene la riqueza de un lenguaje como .NET. WCF se puede escalar fácilmente en una granja de servidores web. Una vez que tenga en cuenta estas y otras razones, puede valer la pena recurrir al enfoque de tres niveles/SOA.

Realmente depende del tamaño de su proyecto, las habilidades del personal, el crecimiento futuro, etc. y eso es algo que solo usted puede determinar.

Answer 2

he empezado a utilizar BLToolkit en base a la información de rendimiento de http://ormeter.net/

Puede definir su modelo en archivos de clase simples, añadir algunos métodos con atributos aplicados y Presto tiene una DAL. Divida una tabla en dos y puede mantener el archivo de clase original mientras crea los nuevos para admitir las tablas divididas. Sólo asegúrese de crear un proyecto de prueba que golpea a todos los métodos para asegurarse de que todo el trabajo con cada versión

Clase

public class DirectoryListing 
    { 
     [PrimaryKey, Identity] 
     public Int64 Id { get; set; } 
     public Int64? OldId { get; set; } 
     public Int32 CategoryId { get; set; } 
     [Nullable] 
     public String CompanyName { get; set; } 
} 

general, seleccione la tabla de funciones valorado:

[SqlQuery("SELECT * FROM Ajax_CategorySearch(@SearchString, @ResultCount)")] 
[Cache(MaxCacheTime = 10, IsWeak = false)] 
public abstract List<String> AjaxCategorySearch(String @SearchString, Int32 @ResultCount = 10); 

O, para usar un proceso almacenado:

[ActionName("SelectById")] 
public abstract Model.DirectoryListing SelectById(Int64 @Id); 

Esto llamará al directorio SPListing_SelectBy Identificación del

Ah, y hacer las cosas de un modo más clásico es fácil también

using (BIFDbManager db = new BIFDbManager()) 
    { 
     var output = db.SetCommand(
      "SQL GOES HERE", 
      db.Parameter("@Id", 1)) 
      .ExecuteList<DAL.Model.DirectoryListing>(); 

     totalrecords = output.Count(); 

     return output; 
    } 

La última pieza del rompecabezas es el gestor de db, que también permite el soporte LINQ.

public class BIFDbManager : DbManager 
{ 
    public BIFDbManager() : base("Connection string name") { } 

    public Table<DirectoryListing> DirectoryListings { get { return GetTable<DirectoryListing>(); } } 
} 

Answer 3

¿Cuánto tiempo puede usted trabajar sin la base de datos? Si es un problema, preséntelo tarde. Y sí, eso probablemente significa que agregas una capa.