How should data be accessed. The working practic

I am newbie C# developer. When I just have started to learn programming thins were pretty simple, you see the problem, you develop solution, test it and it works, that simple.

Then you find out the design patterns and the whole abstraction thing, and you begin to spend more time on the code 开发者_如何学Pythonthat yields no results, always tiring to protect code from possible changes in future. More time less result.

Sorry for the boring introduction, but I just trying to show how frustrated I am now. There is a bunch of data-access technologies provided by Microsoft itself, and even larger bunch of technologies provided by third-party companies.

I don’t have team leader or neighbor super skilled programmer friend, so I have to ask an advice from you.

How do you realize the data access in your real applications written in C#?

From a very overall perspective, I always hide and data access implementation details behind an interface, like this:

public interface IRepository<T> { /*...*/ }

The .NET framework offers a lot of different ways to access data, so I can understand that you are confused. However, at this time, there are only really two or three reasonable options for accessing relational databases:

• NHibernate
• Entity Framework
• (Low-level APIs like IDataReader may still have their place in limited scenarios)

It's often difficult to see the benefit of abstraction without seeing the benefits it provides in a real world application. The best advice I can give is to read up on the SOLID principles then in writing your application try and think about ways the client may come to you and say "Now I need it to do this" which maybe a subtle change to the functionality or a major change. Think about how this would affect your code and in how many places you'd need to make those changes. Once you've made those changes how confident would you be that you haven't broken something else?

Another idea would be to download one of the sample applications. One of my particular favourites is the Data Access Platform sample provided on Codeplex. Try working through this code and see how the abstraction and pattern implementations minimise the impact on the code overall when it comes time to change.

The bottom line is it's easy to learn a programming language but understanding how to build robust solutions with it takes time. Stick with it though because when you do finally get a good understanding of software architecture it's immensely rewarding.

Some points to consider for the DAL: (note: very opinionated, but answers to this question have to be)

• Encapsulate logic behind a Repository
• Use interfaced-based coding
• Use Dependency Injection
• Use a mature ORM like NHibernate/Entity Framework 4.0 (but know when to use SPROC's for db-intensive work)
• Use the Unit of Work pattern
• Prevent SQL Injection attacks by using parameterized queries (or LINQ-Entites, as above)