basic asp.net 2.0 question

[Guest]

I'm coding my first business web app in .NET 2.0 and its only a read only web
app. I'm just pulling data from the database and allowing users to filter the
data in the grids by using dropdowns. I've been reading and seen how you can
drag and drop the controls and bind them that way, though I'm used to coding
using a business layer and datalayer. So my question is since this is only a
view only site, would it make more sense to use the new 'datasource' controls
on 05 or keep coding using a business and datalayers?

I want to use the new tools in 05 but, what is the recommended 'best
practice' way?

 

[Guest]

Having created my first ASP.NET 2.0 web app recently I would say it depends
on what kind of flexibility you need. If the data in the db corresponds to
the viewed form then the SQLDataSource controls can save you a lot of time
(e.g. you don't have to create the other classes). If the data stored needs
to be translated or interpolated before it is displayed on the form then the
businees layer (with ObjectDataSource or manual binding to form fields) is
the way to go.

But you can use an SQLDataSource control and change the sql statement in the
code behind file to match the dropdown selections the user makes, so this
would be the shortcut to getting up and running.

 

[Karl Seguin [MVP]]

I hate those drag and drop controlls. Like you, I spend my time building a
rich business and datalayer. If it's a readonly reporting thing, then I
guess there's no harm. In my experience, larger projects tend to start off
as being "readonly" sites...suddenly you're finding yourself saying "why
didn't I model the business layer?!?!" but you know best if that's actually
gonna happen in this case..

Karl

 

[Guest]

thanks guys, you both have good points.
This site is currently up and running in .NET 1.1 and for the passed 4 years
its remained the same, which is read only (reporting type). Though I like the
drag and drop controls and the time it saves, I think I'm going with the
layers, but using typed datasets, because the current web site uses alot of
the same classes are our internal web site. So this way I can create a
business layer/data layer project and share that for both web applications
and future web and windows applications

thanks

 

[Guest]

if you are going to with data object classes you should look into CodeSmith
for generating patterns of code like properties for your columns etc. to save
time and drudgery

 

[Guest]

CodeSmith?? whats that?

if you are going to with data object classes you should look into CodeSmith
for generating patterns of code like properties for your columns etc. to save
time and drudgery

 

[Guest]

Google says: www.codesmithtools.com

CodeSmith?? whats that?

 

[Cowboy \(Gregory A. Beamer\)]

Without knowing the specs of your application, I cannot give you a firm
answer either way.

The drag and drop functionality will fit most read only implementations
without killing the "best practices" scenario (I disagree with my own
statement a bit, but you can always refactor to libraries and setting up
ASP.NET as pure GUI later, if the app grows). For simple edits, etc., it is
also fine. It is when you step outside of the box that you get squashed.

The main reason to go away from this model is either reuse or
maintainability. If you can reuse the business objects across multiple apps,
then the drag and drop, all in one, objects really, really suck. The same is
true if you need to extend the app, as the all in one objects become far
less maintainable.

If you head to a fairly standard business and data tier, consider ORM
products or a custom code gen for your work. This will help you if you need
schema changes and increase maintainability.

My preference is this (depends from project to project, of course);

Web app/Windows app - pure gui (bind, basic bozo validation)
Facade - translates business to GUI
Business - business type validations primarily, but ensure no bozo
validations blow up below this level, as DB blow ups are expensive
DAL - rather generic or generated
Data - this is generally sprocs on top of the DB (physical storage)

The facade is almost always necessary, IMO, esp. if you think you might ever
offer the same functionality to a smart client.
--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************