Re: Looking for best practice advice on data access for SMALL web sites - not enterprise
- From: "sloan" <sloan@xxxxxxxxx>
- Date: Tue, 27 Jun 2006 12:32:15 -0400
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.Presentation.Web.1
GranadaCoder.Applications.NorthwindManager.Presentation.Winforms1
GranadaCoder.Applications.NorthwindManager.BusinessLogic
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-silver@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:gjTgkVHRlVoEFwcZ@xxxxxxxxxxxxxxxxxxxxxx
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)
.
- Follow-Ups:
- References:
- Prev by Date: Re: ASP DataSet - Strange problem
- Next by Date: Re: automating email with links to records just submitted to an SQL DB using asp.net (vb)
- Previous by thread: Looking for best practice advice on data access for SMALL web sites - not enterprise
- Next by thread: Re: Looking for best practice advice on data access for SMALL web sites - not enterprise
- Index(es):
Relevant Pages
|
