Recently we had a pretty fierce debate internally about the best strategy for data access in architectural design.Ā
Predictably, I played middle-of-the-field, āit dependsā, but one of my co-workers, Omar Besiso was inspired to write this excellent entry.
Iām not going to rehash the same viewpoint I shared last week.
All Iād care to point out is that a database is not necessarily just a backing data store for an application.Ā Especially large or āenterpriseā databases (or applications) and especially given enough time.
Itās important to consider:
– ETL / Loads
– External integration/synchronization (BizTalk/SSIS)
– Replication/fail over (availability)
– Reuse by other applications (particularly web sites, mobile applications etc), and lastly,
– Scalability (linked servers, clustering, partitioning etc)
Iām not stating that Stored Procedures are always the answer, but what I do caution is that any data access design pattern requires ābig pictureā thought.Ā
Security should be considered up front, not when 60% of the development is already complete!
Thereās a place, I think, for both the Entity Framework/LINQ to SQL, traditional Stored Procedures and other tools like NHibernate (etc), but you should justify and rationalise the choice of technology first, and try to ensure it is appropriate for the present and future needs.