Author Topic: Shall we discuss n-tier software development?  (Read 550 times)

0 Members and 1 Guest are viewing this topic.

Bocsius

  • is calmer than you are
  • Senior Member
Shall we discuss n-tier software development?
« on: December 01, 2009, 10:32:36 PM »
So I'm an island within a small company, as I've said on numerous occasions. I'm the lone programmer* in a web design/marketing company. I've been here for two years, dying to get out, and where I worked before, I was someone who was mostly limited to VBA for my programming needs. Due to working alone, it's hard to bounce ideas off people and arrive at some general best practices and just good ideas. Being from a VB background, obviously OOP is something that has been a gradual adapting process.

So anyway, I work in ASP.NET/C#. Obviously, there will be nothing in my presentation code-behind files that talk directly to a database. That's seperated out. But where it goes from there, and how OOP principles should be applied, are kind of fuzzy.

Here's the way I generally work. Keep in mind, we go from project to project in quick fashion. I was at a developer group meeting tonight, and where they were talking about projects that last 3 months on the short end to 12+ months on the longer end, I typically only have a few hours I can devote to any given project. It was a presentation on Agile development, and producing deliverable code every 2 to 4 weeks. The longest dev time I've ever had for any one project has been 130 hours, give or take! Many are far less, say, on the order of one work week if I worked on only that one project at any given time, which isn't often the case. Some amount to just a couple of working days. I wish I could work on something where we could choose to incorporate Agile development methodologies instead of simply being "agile" by default.

So anyway, back to the way I work.

The code-behind on presentation files will work with classes that typically have a 1:1 property:column mapping to a database. So a Customer object will have FirstName, LastName, EmailAddress (et al) properties that correspond to a Customers table with FirstName, LastName, EmailAddress columns. Now, typically, these classes inherit from a base class (or series of base classes) that ease loading and updating of data, incorporating reflection and some generic work to reduce code.

Between the data classes and the database will be a simple intermediary class which I call DataHandler. It's responsible for taking a SQL statement and using it to update or modify data in the database or retrieve a record (or perform a scalar execution for a single value) from the database.

And then, naturally, you have the database, which is typically SQL Server 2005, but has also been MySQL and can really be any database. (The DataHandler class is non-provider specific, it uses a factory to get the right objects based on a providerName attribute in a configuration file.) I don't rely on stored procedures so much, so there's no real logic within the database other than the normalized tables with whatever indices and constraints that are necessary.

So I have the nice split between presentation, nothing data-related is directly being handled there. And of course I have my data block. What I'm concerned about is whether or not I'm doing the in-between work in a way that is recognized as best practice. My primary concern is that within my Customer object, in this example, are four internal properties that deal with SQL construction. A class is responsible for its own data logic, in a sense. No, it doesn't talk directly to the database, but it is what determines what is said to the database. (In reality what happens is that those properties are implementations of abstract properties from a base class, and the base class is what contains the particular methods that make the calls to the DataHandler class, and the DataHandler class is what works directly against the database.) The concern is should the SQL be in the Customer object? If not, where should it be?  Perhaps refactored into a separate class?

It's a process that works for me. The base classes and the data handler are classes that I will reuse from project to project. And it's fairly simple to put together business classes to utilize the imported code. But just because the process works doesn't mean I'm not interested in something that would be better.

---------------------------

*lone programmer qualification

There are some people in Romania that we outsource work to from time to time, but I do not have a direct working relationship with them.

There is another resource quasi-local who contracts with us remotely. Interestingly enough, he wrote a book on C#, yet the one site where we work on the same codebase (just different parts of it), I can see that he doesn't really bother to do much separation of presentation and data at all. Yes, there will be some reusable classes defined, but quite often the presentation code-behind will be constructing SQL statements and then going to the database (usually through a handler, though). So while I guess he's more senior than me, I don't really follow his lead in terms of working with data.
« Last Edit: December 02, 2009, 12:19:15 AM by Bocsius »

Olivia Wilde Homo

  • Proud Kinkshamer
  • Senior Member
Re: Shall we discuss n-tier software development?
« Reply #1 on: December 01, 2009, 10:33:34 PM »
We shall not.
🍆🍆

Bocsius

  • is calmer than you are
  • Senior Member
Re: Shall we discuss n-tier software development?
« Reply #2 on: December 01, 2009, 10:36:28 PM »
(moved to OP)
« Last Edit: December 01, 2009, 10:55:46 PM by Bocsius »