views:

364

answers:

5

I am starting work on my first business (application + database) type application, using c# and sql I'm completely new to this,

What tips do you have for me?

What should I look for?

What concepts should I understand?

+7  A: 

My tip is to get started and come back when you actually have a concrete question. If it makes you feel more prepared, go read some more C# and SQL books first.

mquander
+2  A: 

Just start writing code. You're going to have to throw is away later when you figure out what going on, but that's alright.

stevedbrown
+1  A: 

Well, I'd say you've come to the right site if you start asking specific questions.

Some of our highest rated questions, however, will give you tons and tons of reading material, books, link to other sites, etc. Here is the URL

http://stackoverflow.com/questions?sort=votes

Raj More
+1  A: 

General tips:

  1. Get some help from somebody who has done this before. There is no way you're going to pull this off by yourself unless you allow for plenty of time to learn on the job.
  2. Don't get distracted by the technical details -- make sure you understand the business. If you don't know why you're building the app (or your clients don't know why they need it) no good can come from it.

As far as what you should look for or how much you need to understand, I don't know the scope of the application you are trying to build -- thus I can't give any intelligent advice. A real-time financial system used by thousands of concurrent users is different from a small retail site that gets hit by hundreds. So my only look for/understand advice is this: don't overengineer your solution.

micahtan
+2  A: 

While your question is broad, here is the number one thing I 'wish I knew' when I started out with business apps, kinda specific but it's pretty universal:

Writing business apps is made considerably easier by setting up a solid DAL (Data access layer) and abstracting your data access out and away from the rest of your application. That way all of your SQL is in one place and not strewn throughout your code.

Some golden ideas to read up on in this area are 'ORM' (object-relational mapping, as you're using C#, Linq to SQL could be a nice place to start) - this maps your database access to actual classes. If you have a good database design you might even find you have very little SQL work to do at all.

Another nice practice is using the Repository pattern, which effectively encapsulates all your data access into a single class (at least in the simple case - of course in bigger apps you might have multiple). Then in order to access any data, you always go via the repository. This is typically done via an interface which defines the repository, which then allows you to implement multiple concrete implementations. For example, you might want to fetch your data directly from an SQL server, but later on or in an alternative application you might want to use a web service to fetch data instead - no need to re-write everything, just drop in a new repository class! The interface stays the same, so the rest of your application doesn't know any different :D)

This is a pretty broad overview (and a bit of a mind dump sorry), and I'm certainly no expert, but believe me, good data access practices certainly make your life easier!

CapBBeard