Data Access Layer yaklaşımları nasıl olmalı

There are many different approaches to accessing data these days, and the approach you use will depend not only on the type of application you build, but also on your personality (or your team’s personality). There is no single data access strategy that can work for all applications and all teams.

The approach in this chapter uses the tooling of Visual Studio and will get you up and running quickly. There isn’t anything explicitly wrong with the code; however, for some developers and some projects, the approach is too simplistic. The scaffolding we use in this chapter assumes you are building an application that needs to implement basic create, read, update, and delete (CRUD) functionality. Many applications exist only to provide CRUD functionality with basic validations and a minimal amount of business workfl ows and business rules. The scaffolding works well for these applications.

For more complex applications you’ll want to investigate different architectures and design patterns that can suit your needs. Domain-driven design (DDD) is one approach that teams use to tackle complex applications. Command-query responsibility segregation (CQRS) is also a pattern gaining mindshare among teams wrestling with diffi cult applications.

Some of the popular design patterns used in DDD and CQRS include the repository and unit of work design patterns. For more information on these design patterns, see http://msdn.microsoft.com/en-us/library/ff714955.aspx. One of the advantages to the repository pattern is that you can create a formal boundary between the data access code and the rest of your application. This boundary can improve the ability to unit test your code, which is not one of the strengths of the code generated by the default scaffolding (because of hard-coded dependencies on the Entity Framework).