current community

your communities

more stack exchange communities

Stack Exchange Inbox Reputation and Badges
tour help
Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.
up vote 1 down vote favorite

In 2 weeks I will be starting a new job as a software developer in a company that currently does not employ any professional programmers. My first task will be to rewrite a Excel/VBA application in C#, with an SQL back end.

I am currently a C# developer but we don't use a database back end; previously I was a database administrator but I didn't program. I have very little experience at joining up the two worlds.

What are the options for modelling the database access in a C# desktop application with a SQL Server back end? I would want to have some separation between the layers (database, logic, user interface).

share|improve this question

closed as too broad by Robert Harvey, MichaelT, Snowman, durron597, GlenH7 Apr 16 at 19:54

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.
    
recommended reading: What is the problem with “Pros and Cons”? –  gnat Apr 15 at 7:34
1  
I can edit it so that it doesn't ask for pros/cons and doesn't mention solutions if you think that would be better @gnat –  Paul Richards Apr 15 at 7:37
    
@PaulRichards do you know about the Entity Framework? If not just check it out. –  Knerd Apr 15 at 7:50
1  
@PaulRichards what do you mean? For the EF check here: msdn.microsoft.com/en-us/data/ee712907 –  Knerd Apr 15 at 8:07
1  
@PaulRichards to address the rest of your question, check on WPF and MVVM. That should help you ;) –  Knerd Apr 15 at 8:09

2 Answers 2

up vote 1 down vote accepted

What I think you want is domain driven design, In simple terms separation of concerns. Read about it and you are good to go. To keep it simple since you say yo new, Just have User Interface layer in its own project, a service / logic layer in its own project. a data access layer in its own project and other layers depending on the project. For the data access i would recommend you use Entity Framework to bind with your database (preferable database first option since you have db admin background). Now read and get familiar with Linq and Entity Framework and i think you are good to go.

share|improve this answer
    
I have started learning the entity framework and I think this will save me time, thanks. In future I am going to learn WPF but for now am going to stick to winforms. –  Paul Richards Apr 16 at 10:13
up vote -1 down vote

You definitely should design your application with discrete layers - data access, business logic, UI etc.

However, I'm going to go against the trend and advise you not to use Entity Framework for your data access layer.

An ORM should be purely a mapper between database and POCO classes. In my eyes, EF breaks the single responsibility principle by trying to do too much - caching, change tracking, lazy loading etc etc. All this extra functionality places too heavy a load on performance.

Instead, I suggest that you should use a simple micro-ORM such as Dapper, Peta Poco or OrmLite. Your choice will depend on the exact functionality required and whether you have an existing database. My vote would go to OrmLite, as it supports code-first design (generating database elements from C# class definitions) and async/await functionality.

share|improve this answer
    
Srp applies to a class not a framework. And its a principal mot a hard and fast rule. –  Andy Apr 16 at 1:14
    
So what's DbContext if not a class? –  Peregrine Apr 16 at 5:47
    
My key point still stands though - don't blindly choose EF just because it is the "official Microsoft Orm" unless you really need all it's features. –  Peregrine Apr 16 at 5:48
    
SRP is useful when you are maintaining the class; you're not worrying about maintaining DbContext yourself, someone else is, you should only care that it works. What you claim is your main point appears as a couple of sentences in your entire answer, you just spout out that you believe EF does "too much" and should just avoid it in favor of ORMs which do less. –  Andy Apr 16 at 16:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.