<p>I started a project a long time ago and created a <strong>Data Access Layer</strong> project in my solution but have never developed anything in it.  What is the purpose of a data access layer?  Are there any good sources that I could learn more about the Data Access Layer?</p>

[{'answer_id': 59948, 'author': 'GEOCHET', 'author_id': 5640, 'author_profile': 'https://Stackoverflow.com/users/5640', 'pm_score': 0, 'selected': False, 'text': '<p>I recommend you read up here: <a href="http://msdn.microsoft.com/en-us/practices/default.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/practices/default.aspx</a>\nUsing a DAL will help you isolate your data access from your presentation and business logic. I use it a lot so that I can easily swap out (through reflection and dynamically loading assemblies) data providers. </p>\n\n<p>Read up, lots of good info there.</p>\n\n<p>Also, look into the <a href="http://msdn.microsoft.com/en-us/library/cc511547.aspx" rel="nofollow noreferrer">Data Access Block</a> if you are planning on using .NET. It can be a big help.</p>\n'}, {'answer_id': 59950, 'author': 'Scott Dorman', 'author_id': 1559, 'author_profile': 'https://Stackoverflow.com/users/1559', 'pm_score': 3, 'selected': False, 'text': '<p>A data access layer follows the idea of "separation of concerns" whereby all of the logic required for your business logic to interact with your data layer (database) is isolated to a single set of classes (layer). This allows you to more easily change the backend physical data storage technology (move from XML files to a database, or from SQL Server to Oracle or MySQL, for example) without having a large impact (and if done right having zero impact) to your business logic.</p>\n\n<p>There are a lot of tools that will help you build your data layer. If you search for the phrase "object relational mapper" or "ORM" you should find some more detailed information.</p>\n'}, {'answer_id': 59953, 'author': 'Guy Starbuck', 'author_id': 2194, 'author_profile': 'https://Stackoverflow.com/users/2194', 'pm_score': 3, 'selected': False, 'text': '<p>The DAL should abstract your database from the rest of your project -- basically, there should be no SQL in any code other than the DAL, and only the DAL should know the structure of the database.</p>\n\n<p>The purpose is mainly to insulate the rest of your app from database changes, and to make it easier to extend and support your app because you will always know where to go to modify database-interaction code.</p>\n'}, {'answer_id': 59956, 'author': 'swilliams', 'author_id': 736, 'author_profile': 'https://Stackoverflow.com/users/736', 'pm_score': 5, 'selected': False, 'text': '<p>In two words: <a href="http://en.wikipedia.org/wiki/Loose_coupling" rel="noreferrer">Loose Coupling</a></p>\n\n<p>To keep the code you use to pull data from your data store (database, flat files, web services, whatever) separate from business logic and presentation code. This way, if you have to change data stores, you don\'t end up rewriting the whole thing.</p>\n\n<p>These days, various ORM frameworks are kind of blending the DAL with other layers. This typically makes development easier, but changing data stores can be painful. To be fair, changing data stores like that is pretty uncommon.</p>\n'}, {'answer_id': 59957, 'author': 'Esteban Araya', 'author_id': 781, 'author_profile': 'https://Stackoverflow.com/users/781', 'pm_score': 1, 'selected': False, 'text': '<p>The purpose is to abstract out the database access details that other parts of your application need not be concerned about.</p>\n'}, {'answer_id': 59959, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 1, 'selected': False, 'text': '<p>A data access layer is used to abstract away the storage and retrieval of data from its representation.  You can read more about this kind of abstraction in 1994\'s <a href="https://rads.stackoverflow.com/amzn/click/com/0201633612" rel="nofollow noreferrer" rel="nofollow noreferrer">Design Patterns</a></p>\n'}, {'answer_id': 59964, 'author': 'theschmitzer', 'author_id': 2167252, 'author_profile': 'https://Stackoverflow.com/users/2167252', 'pm_score': 1, 'selected': False, 'text': '<p>The purpose is to abstract the data storage retrieval mechanism from data usage and manipulation.</p>\n\n<p>Benefits:</p>\n\n<ul>\n<li>Underlying storage can change (switch from Oracle to MSSQL for example), and you need a way to localize those changes</li>\n<li>Schema changes - see above</li>\n<li>You want a way to run disconnected from your db (demo mode): Add file serialization/deserialization to the DAL</li>\n</ul>\n'}, {'answer_id': 59975, 'author': 'Jonathan Allen', 'author_id': 5274, 'author_profile': 'https://Stackoverflow.com/users/5274', 'pm_score': 3, 'selected': False, 'text': "<p>Data access layers make a lot of sense when many different parts of your application need to access data the same way.</p>\n\n<p>It also makes sense when you need access the same data in many different ways. For example, how word processors can read many different file types and silently convert them into the application's internal format.</p>\n\n<p>Keep in mind that a DAL can also be very counter productive. If you are building a system where data access performance is critical, separating it from the business logic can make some vital optimizations impossible.</p>\n"}, {'answer_id': 4237176, 'author': 'Shiv Kumar', 'author_id': 501146, 'author_profile': 'https://Stackoverflow.com/users/501146', 'pm_score': 5, 'selected': False, 'text': '<p>There are two primary purposes of a Data Access Layer</p>\n\n<ol>\n<li><p>Abstract the actual database engine\nor other data store, such that your\napplications can switch from using\nsay Oracle to using MS SQL server</p></li>\n<li><p>Abstract the logical data model such\n    that your Business Layer is\n    decoupled from this knowledge and is\n    agnostic of it. Giving you the\n    ability to modify the logical data\n    model without impacting the business\n    layer</p></li>\n</ol>\n\n<p>Most answers here have provided the first reason. In my mind it is the second that is far more important. Essentially your business layer should not be aware of the logical data model that is in use. Today with ORMs and Linq #2 seems to go out the window and people tend to forget (or are not able to see the fine lines that do and should exist) about #2.</p>\n\n<p>Essentially, to get a good understanding of the purpose and function of a Data Layer, you need to see things from the Business Layer\'s perspective, keeping in mind that the Business layer should be agnostic of the logical data model of your data store.</p>\n\n<p>So each time the business layer need data for example, if should ask for the data it needs in a very simple logical data model agnostic way. So it would make a call into the Data Access Layer such as:</p>\n\n<pre><code>GetOrdersForCustomer(42)\n</code></pre>\n\n<p>And it gets back exactly the data it needs without being aware of what tables store this information of or relationship exists etc.</p>\n\n<p>I\'ve written an article on my blog that goes into more details.</p>\n\n<p><a href="http://www.matlus.com/the-purpose-and-function-of-a-data-access-layer/" rel="noreferrer">The Purpose and function of a Data Access Layer</a></p>\n'}, {'answer_id': 50321547, 'author': 'Christopher Williams', 'author_id': 4393596, 'author_profile': 'https://Stackoverflow.com/users/4393596', 'pm_score': 0, 'selected': False, 'text': "<p>Something which hasn't been brought up that I thought I'd add is that having a DAL allows you to improve the security of your system. For instance, the DB and DAL could run on server(s) inaccessible to the public while the business logic can run on a public facing server such that the public server can't run raw SQL on the DB. This could help mitigate a lot of damage should the public server be compromised. </p>\n"}]
['https://Stackoverflow.com/questions/59942', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/299/']