«

Hello,

MSDN (amongst other places) is full of helpful advice on ways to do data
access, but they all seem geared to wards enterprise applications. Maybe
I'm in a minority, but I don't have those sorts of clients. Mine are all
small businesses whose sites will never reach those sorts of scales. I
deal with businesses whose sites get maybe a few hundred visitors per
day (some not even that much) and get no more than ten orders per day.
This is not enterprise level and does not require the weight of coding
and layers that enterprise applications need.

I'm looking for a guide to best practices for small sites. I work alone,
and am unlikely to change that, so the weight of extra layers and coding
to protect a database from the person coding the presentation layer
isn't necessary. I am happy to split the application into layers, but
only where there is some real benefit. Most advice I have seen involves
building a data access layer, a business logic layer and a presentation
layer. This seems over the top for a small site maintained by one
person.

Up until now, I have treated the .aspx file as the presentation layer,
the code-behind (and the client-side validation in the .aspx file) as
the business logic layer, and have a generic method in a utilities
function that actually communicates with the database. I want to know if
this is good practice, or if there is a better way.

I have been reading the tutorials at
http://www.asp.net/learn/dataaccess/ and they seem keen on using the
Data Table object in Visual Studio that allows you to create a
connection to a database without writing code. They also build a logic
layer, which seems unnecessary in my case, but I am willing to be
educated!!

Any and all comments welcome. Please remember, I am *not* writing for
the enterprise, I am looking for the best solution for small sites.

TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

The only thing I do different for "small" versus "enterprise", is that I
sometimes create subfolders instead of actual different assemblies.

http://sholliday.spaces.msn.com/PersonalSpace.aspx 6/5/2006
5/24/2006
(here is example of my tier system)

To contrast "Enterprise" vs "Small App"

Enterprise would be: (for a fictional NorthwindManager application)
GranadaCoder.Applications.NorthwindManager.Present ation.Web.1
GranadaCoder.Applications.NorthwindManager.Present ation.Winforms1
GranadaCoder.Applications.NorthwindManager.Busines sLogic
GranadaCoder.Applications.NorthwindManager.Data
(each of the above would be a seperate assembly)

For a small applications.. I'd have 1 application:
GranadaCoder.Applications.NorthwindManager
and then different folders:

GranadaCoder.Applications.NorthwindManager.Web
GranadaCoder.Applications.NorthwindManager.Biz
GranadaCoder.Applications.NorthwindManager.DAL



You''ll notice that a few things:
1: I can't have 2 presentation layers in the small-app method. I can
have 1, because I have to choose Web or Winforms and marry myself to it.
2. Biz contains business objects, logic
3. Data contains objects which return (DataSets, IDataReader's, Scalars,
and voids/nothings)

The deal is that after doing so many Enterprise applications, I know when
I'm violiating the rules.
Its tempting to throw a business object over to the datalayer at times,
which isnt' possible in the enterprise setup, because .Data does not
reference .BusinessLogic

Tiered development is a mindset at times. Not just a "rule1, rule2, etc".

It isn't just about protecting the deep secret code from the presentation
guys. Its organizing code into compartments to help with maintenance and
for your own sanity.

Even the smallest of web project that I do, I do them correctly, using the
"folder system" above. While I ~could remove the business layer object at
times, it just goes so against my grain that I don't do it. And every once
in a while. you have to add something in and you go "ahh, the wisdom of
putting in the good business layer up front".

You can check my blog.

The other hint I can give is that:

strong typed datasets (to me anyways) is the po man's business
object/collection. They are fine for small projects.

Finally, if I know (ever) that I might need 2 presentation layers (a web app
and a winforms app), then I do it all in seperate layers up front.




"Alan Silver" <alan-> wrote in message
news:...
> Hello,
>
> MSDN (amongst other places) is full of helpful advice on ways to do data
> access, but they all seem geared to wards enterprise applications. Maybe
> I'm in a minority, but I don't have those sorts of clients. Mine are all
> small businesses whose sites will never reach those sorts of scales. I
> deal with businesses whose sites get maybe a few hundred visitors per
> day (some not even that much) and get no more than ten orders per day.
> This is not enterprise level and does not require the weight of coding
> and layers that enterprise applications need.
>
> I'm looking for a guide to best practices for small sites. I work alone,
> and am unlikely to change that, so the weight of extra layers and coding
> to protect a database from the person coding the presentation layer
> isn't necessary. I am happy to split the application into layers, but
> only where there is some real benefit. Most advice I have seen involves
> building a data access layer, a business logic layer and a presentation
> layer. This seems over the top for a small site maintained by one
> person.
>
> Up until now, I have treated the .aspx file as the presentation layer,
> the code-behind (and the client-side validation in the .aspx file) as
> the business logic layer, and have a generic method in a utilities
> function that actually communicates with the database. I want to know if
> this is good practice, or if there is a better way.
>
> I have been reading the tutorials at
> http://www.asp.net/learn/dataaccess/ and they seem keen on using the
> Data Table object in Visual Studio that allows you to create a
> connection to a database without writing code. They also build a logic
> layer, which seems unnecessary in my case, but I am willing to be
> educated!!
>
> Any and all comments welcome. Please remember, I am *not* writing for
> the enterprise, I am looking for the best solution for small sites.
>
> TIA
>
> --
> Alan Silver
> (anything added below this line is nothing to do with me)

I agree with Darren also. . as in.

The time you pay up front .. always seems to pay off later.

Spaghetti code is always harder to maintain.

I only do the subfolder thing ... knowing I'm not violating the rules.
If I wasn't sure about that, then I'd always stick with the tiers as
seperate layers/assemblies.




"Darren Kopp" <> wrote in message
news: oups.com...
> I've found that building websites (even small ones) with the 3-tier
> approach is more work, but it's a lot easier to maintain as well. Your
> code is a lot cleaner and easier to go through when something pop's up
> that you didn't expect, which can sometimes help you save time rather
> than it taking longer.
>
> I've done both ways, now i do strictly do the 3-tier approach. I'm
> typically the only developer as well. That's my 2 cents.
>
> -Darren Kopp
>

I've found that building websites (even small ones) with the 3-tier
approach is more work, but it's a lot easier to maintain as well. Your
code is a lot cleaner and easier to go through when something pop's up
that you didn't expect, which can sometimes help you save time rather
than it taking longer.

I've done both ways, now i do strictly do the 3-tier approach. I'm
typically the only developer as well. That's my 2 cents.

-Darren Kopp

In article < .com>,
Darren Kopp <> writes
>I've found that building websites (even small ones) with the 3-tier
>approach is more work, but it's a lot easier to maintain as well. Your
>code is a lot cleaner and easier to go through when something pop's up
>that you didn't expect, which can sometimes help you save time rather
>than it taking longer.

I can see the logic in that, but I'm still not really sure why people
advocate a separate business logic layer. In the examples in the
tutorials I linked before, most of the logic was stuff that would be
caught by validation rules anyway, so I'm not sure what the BLL adds,
other than weight.

Please enlighten me

>I've done both ways, now i do strictly do the 3-tier approach. I'm
>typically the only developer as well. That's my 2 cents.

OK, good to hear it from someone in a similar position. What do you
think of the Visual Studio DataSet approach? This seems like a neat and
tidy way of building a DAL without coding. Any thoughts?

--
Alan Silver
(anything added below this line is nothing to do with me)

In article <>, sloan
<> writes
<snip>
>Spaghetti code is always harder to maintain.

Who says that a non-layered approach results in spaghetti code? I have
never really done layered development (partly because I'm self taught,
and never learnt that, which is why I'm asking these questions), but
would modestly claim that I do not write spaghetti code.

--
Alan Silver
(anything added below this line is nothing to do with me)

In article <#>, sloan
<> writes
>The only thing I do different for "small" versus "enterprise", is that
>I sometimes create subfolders instead of actual different assemblies.
<snip>

OK, I admit it, you lost me

It's when I read stuff like this that I wonder why I need such
complexity to do simple tasks. Maybe it's my lack of understanding, but
this all looks very weighty for what it does. You end off saying...

>strong typed datasets (to me anyways) is the po man's business
>object/collection. They are fine for small projects.

Do I take that to mean that the approach shown in those tutorials is OK?
I can see the logic and benefit of those, although I'm still not sure
why I need a BLL. It all looks a whole lot simpler than the stuff you
wrote before!!

Thanks for the reply, any further help appreciated.

--
Alan Silver
(anything added below this line is nothing to do with me)

In my examples, I do not use a strongly typed dataset.

I use objects and collections. (<List> in 2.0)

Instead of a strongly typed dataset, with a Customer (table) and a Orders
(table), I have

public class Customer

public class Order

and Customer has a child collection called
public OrdersCollection AllOrders


I happen to use a DataReader to populate my objects and collections. Since
IDataReader's are better performing than DataSets. (IDataReader's use the
fire_hose model, where you read the records 1 at a time, in a forward only
manner)

Developing those objects and collections takes time. However, for a serious
application, that's probably the way to go.

Using the strongly typed datasets kinda of give you the same functionality.
But its (my take) kind of the po's mans way of doing it.
It works.

For small apps, I use strongly typed datasets. Small, as in, ... I once
wrote an address collector for colleciting addresses after I got engaged.

I used to use strongly typed datasets all the time, but someone showed me
the light on that.
If you download the 1.1 example, you can also check out performance times.


...

//
Who says that a non-layered approach results in spaghetti code?
//

I can't "prove" it to you, I can only tell you thats how I (and alot of
others) feel about it.
Software Engineering is a lifelong process of maturing. When you start
looking at things like Design Patterns (www.dofactory.com), you
realize that what you thought was great 1 year ago, was not really so great.

When you start figuring out things like the Factory Pattern ... and how you
can make your code smarter.... you look back and go "Geeze...that stuff I
wrote before was pretty deficient".

That's my take. I can't prove it. I can only offer advice.

//
but
would modestly claim that I do not write spaghetti code.
//


Do you ever watch "The Office" on NBC?
There's a guy on there named Jim, (Tim in the British version). Jim is the
cool, does a good job but not too seriously guy... in the office.
Most people .. in their minds .. think "Yeah, I'm like Jim". Because Jim
handles situations with the most coolness and common sense.
And as Jim deals with other people in the office, viewers think "Yeah, I'm
like Jim because I've encountered people like that in my office"

The reality is that there are alot of people watching the The Office, and
they are not and they are really are like:
The insecure, attention needing, boss who thinks he's funnier than sliced
bread.
The butt kissing work nut, always trying to impress the boss.
The no fun anal person, who gets mad everytime somebody tries to have any
fun.
The non vocal good workers, well rounded and pleasant. Not too high above
the radar, not too far below the radar.


3 years ago, I thought I was a really good developer. That I didn't do
stupid stuff. I mean, I could wrap my arms around a business problem and
get it solved.
3 years ago, I could probably see about 1 or 2 levels down the road in my
design process.

Then I worked in a group of very good developers, and realized how deficient
I was. Which got me on the right path toward maturing as a developer.
Now I can see about 3 levels, sometimes, 4 levels down the road. But I am
still deficient.... as I said, its a lifelong process.


My non technical advice is that.. sometimes its hard to be self-aware,
especially in more isolated environments. I'm not trying to attack, I'm
just letting you know as I look back, that's how I feel, mainly because of
the boat I was in myself.

You might want to try looking at the source code of
http://www.eecs.wsu.edu/paint.net/
Paint.NET

That is a pretty well designed application which does some serious stuff.

I'm not omniscient, I'm just offering my advice.

Good luck with your pursuit.





"Alan Silver" <alan-> wrote in message
news:m1+...
> In article <#>, sloan
> <> writes
> >The only thing I do different for "small" versus "enterprise", is that
> >I sometimes create subfolders instead of actual different assemblies.
> <snip>
>
> OK, I admit it, you lost me
>
> It's when I read stuff like this that I wonder why I need such
> complexity to do simple tasks. Maybe it's my lack of understanding, but
> this all looks very weighty for what it does. You end off saying...
>
> >strong typed datasets (to me anyways) is the po man's business
> >object/collection. They are fine for small projects.
>
> Do I take that to mean that the approach shown in those tutorials is OK?
> I can see the logic and benefit of those, although I'm still not sure
> why I need a BLL. It all looks a whole lot simpler than the stuff you
> wrote before!!
>
> Thanks for the reply, any further help appreciated.
>
> --
> Alan Silver
> (anything added below this line is nothing to do with me)

In article <>, sloan
<> writes
>
>In my examples, I do not use a strongly typed dataset.
<snip>
>Developing those objects and collections takes time. However, for a serious
>application, that's probably the way to go.

OK, forgive me for flogging this one, but I really want to understand
this properly. Why is this the way to go? What advantage does it have
over a strongly typed dataset?

>Using the strongly typed datasets kinda of give you the same functionality.
>But its (my take) kind of the po's mans way of doing it.

Again, why? I'm not saying you're wrong, I just want to know why. I'm
really genuinely here to learn best practices, but I want to understand
why something is best, not just do it 'cos someone said that's better


<snip>
>That's my take. I can't prove it. I can only offer advice.

That's OK, I came here for advice and I'm happy to hear it. I only ask
back on it to try and get it clear. I'm not saying you're wrong.

>//
>but
>would modestly claim that I do not write spaghetti code.
>//
>
>
>Do you ever watch "The Office" on NBC?

Nah, don't have a TV. Can't stand them.

<snip>
>3 years ago, I thought I was a really good developer. That I didn't do
>stupid stuff. I mean, I could wrap my arms around a business problem and
>get it solved.

OK, right off let me say I don't consider myself "really good." I would
like to consider myself capable and fairly good, but really good? Nah.

<snip>
>My non technical advice is that.. sometimes its hard to be self-aware,
>especially in more isolated environments. I'm not trying to attack, I'm
>just letting you know as I look back, that's how I feel, mainly because of
>the boat I was in myself.

That's fine, I appreciate the feedback

OK, so having got this far, I could do with some guidance. Looking at
that site, it looks way above my head. I wouldn't know where to start.
Furthermore, the factory method that you mentioned looks like a very
complex way to do a simple job. What's the benefit in doing it this way?
I know I'm asking a big question here, but as a newbie to the idea of
design patterns, I can't see what they offer me. Why would I invest so
much time learning and implementing something so complex for a simple
job like grabbing a datareader full of product names?

Again, not criticising, just trying to understand.

>You might want to try looking at the source code of
>http://www.eecs.wsu.edu/paint.net/
>Paint.NET
>
>That is a pretty well designed application which does some serious stuff.
>
>I'm not omniscient, I'm just offering my advice.

That's what I asked for

>Good luck with your pursuit.

Thanks. Any further advice and comments welcome.

--
Alan Silver
(anything added below this line is nothing to do with me)

This article:
http://msdn.microsoft.com/library/de...tml/boagag.asp

sheds some light. I read the whole thing top to bottom about every 3 or 4
months.

There are pros and cons to each. The article describes them a lot better
than I could.

Whenever I use DataSets', and I have to find 1 employee among N number of
employees (in a strong dataset, in an Employee (table).
I have to use the .Select method. I then have to do some casting.

Type Safety would be the big reason for me. When I defined an Employee
(class) .. with an AllOrders (property), I know exactly what I have.

A small part:
If you do the business objects, then you have alot more options for
remoting, serialization. And scaling your application if you ever need to.
But again, that's "big", and you're interested in "not big".

With 2.0, and <List>'s, .. you don't have to write your own CollectionBase's
(most of the time).
Which makes the use of objects even easier.

...




"Alan Silver" <alan-> wrote in message
news:...
> In article <>, sloan
> <> writes
> >
> >In my examples, I do not use a strongly typed dataset.
> <snip>
> >Developing those objects and collections takes time. However, for a
serious
> >application, that's probably the way to go.
>
> OK, forgive me for flogging this one, but I really want to understand
> this properly. Why is this the way to go? What advantage does it have
> over a strongly typed dataset?
>
> >Using the strongly typed datasets kinda of give you the same
functionality.
> >But its (my take) kind of the po's mans way of doing it.
>
> Again, why? I'm not saying you're wrong, I just want to know why. I'm
> really genuinely here to learn best practices, but I want to understand
> why something is best, not just do it 'cos someone said that's better
>
>
> <snip>
> >That's my take. I can't prove it. I can only offer advice.
>
> That's OK, I came here for advice and I'm happy to hear it. I only ask
> back on it to try and get it clear. I'm not saying you're wrong.
>
> >//
> >but
> >would modestly claim that I do not write spaghetti code.
> >//
> >
> >
> >Do you ever watch "The Office" on NBC?
>
> Nah, don't have a TV. Can't stand them.
>
> <snip>
> >3 years ago, I thought I was a really good developer. That I didn't do
> >stupid stuff. I mean, I could wrap my arms around a business problem and
> >get it solved.
>
> OK, right off let me say I don't consider myself "really good." I would
> like to consider myself capable and fairly good, but really good? Nah.
>
> <snip>
> >My non technical advice is that.. sometimes its hard to be self-aware,
> >especially in more isolated environments. I'm not trying to attack, I'm
> >just letting you know as I look back, that's how I feel, mainly because
of
> >the boat I was in myself.
>
> That's fine, I appreciate the feedback
>
> OK, so having got this far, I could do with some guidance. Looking at
> that site, it looks way above my head. I wouldn't know where to start.
> Furthermore, the factory method that you mentioned looks like a very
> complex way to do a simple job. What's the benefit in doing it this way?
> I know I'm asking a big question here, but as a newbie to the idea of
> design patterns, I can't see what they offer me. Why would I invest so
> much time learning and implementing something so complex for a simple
> job like grabbing a datareader full of product names?
>
> Again, not criticising, just trying to understand.
>
> >You might want to try looking at the source code of
> >http://www.eecs.wsu.edu/paint.net/
> >Paint.NET
> >
> >That is a pretty well designed application which does some serious stuff.
> >
> >I'm not omniscient, I'm just offering my advice.
>
> That's what I asked for
>
> >Good luck with your pursuit.
>
> Thanks. Any further advice and comments welcome.
>
> --
> Alan Silver
> (anything added below this line is nothing to do with me)