«

I have done my first big project with .net 2.0. I like how easy it is to
build 3 tier apps with strongly typed datasets and a business logic layer.
The main thing I dislike is how to handle presentation logic:

The formview: is there any way of getting around having separate forms for
the insert and update as often they are identical.
I like databinding but dislike the formview type controls, is there anyway
to databind to textboxes from a business object with out a formview or
gridview.
What are people's opinions on the formview. Once you start nesting controls
and needing to apply presentation logic the events are a pain and you can't
access them for instance in the page load event
You end up with code all over the place to handle the inserts and updates.
I want to learn more about design patterns e.g. MVC/MVP is the formview
appropriate with these patterns

I am tempted just to use a panel and do the binding manually, it seems less
hassle. What is the best approach?

Regards, Chris.

If you are doing 2.0, I believe you can do DataBindings, AND handle nulls.

If you're in 1.1, you may have some obstacles.

Google this:
http://www.google.com/search?hl=en&q...new+Binding%22

DataBindings "new Binding"

One link you'll find:
http://msdn2.microsoft.com/En-US/lib...abindings.aspx

That'll get your started on "individual objects" and binding.


The issue comes with you have to bind to a value that's not populated.
That's where a "new" vs "edit" will show up, and 2.0 has better handling for
that.



Unforunately, I don't have the exact info with me....but that'll get you
started.






"Fresno Bob" <> wrote in message
news:...
>I have done my first big project with .net 2.0. I like how easy it is to
>build 3 tier apps with strongly typed datasets and a business logic layer.
>The main thing I dislike is how to handle presentation logic:
>
> The formview: is there any way of getting around having separate forms for
> the insert and update as often they are identical.
> I like databinding but dislike the formview type controls, is there anyway
> to databind to textboxes from a business object with out a formview or
> gridview.
> What are people's opinions on the formview. Once you start nesting
> controls and needing to apply presentation logic the events are a pain and
> you can't access them for instance in the page load event
> You end up with code all over the place to handle the inserts and updates.
> I want to learn more about design patterns e.g. MVC/MVP is the formview
> appropriate with these patterns
>
> I am tempted just to use a panel and do the binding manually, it seems
> less hassle. What is the best approach?
>
> Regards, Chris.

The best way to deal with the FormView is to use an ObjectDataSource
(ODS). In the GetDataById(id) method you can pass in a -1 for "new
record" and have the GetDataById(id) method create a "new pseudo record"
for you. (ie, it won't exist in the database, but the FormView will
think it does) Then in the "Update" method, you check the ID for -1 and
do an insert if it is -1, otherwise you do an update.

That takes care of about 80% of any real problems I've had. Nesting
controls using user controls is a problem since you can't bind to them
but I honestly haven't had to do that too often and if I have it's been
for controls that are bound to a separate ODS anyhow. So, all I need to
do is pass the parent ID to the user control and let the ods in that
control do whatever work needs to be done.

-----Original Message-----
From: Fresno Bob [private.php?do=newpm&u=]
Posted At: Thursday, November 22, 2007 7:04 PM
Posted To: microsoft.public.dotnet.framework.aspnet
Conversation: Presentation
Subject: Presentation

I have done my first big project with .net 2.0. I like how easy it is to

build 3 tier apps with strongly typed datasets and a business logic
layer.
The main thing I dislike is how to handle presentation logic:

The formview: is there any way of getting around having separate forms
for
the insert and update as often they are identical.
I like databinding but dislike the formview type controls, is there
anyway
to databind to textboxes from a business object with out a formview or
gridview.
What are people's opinions on the formview. Once you start nesting
controls
and needing to apply presentation logic the events are a pain and you
can't
access them for instance in the page load event
You end up with code all over the place to handle the inserts and
updates.
I want to learn more about design patterns e.g. MVC/MVP is the formview
appropriate with these patterns

I am tempted just to use a panel and do the binding manually, it seems
less
hassle. What is the best approach?

Regards, Chris.

"Fresno Bob" <> wrote in message
news:...

> What is the best approach?

There isn't one - as with virtually everything in ASP.NET, it comes down to
personal preference...

I agree with you about not having separate forms for inserting and
updating - I never do that. Generally speaking, I use two forms for each
business "object" / "entity" / whatever. E.g. if I need to maintain
customers, then I'll have a customers.aspx page which lists existing
customers in a GridView to allow the user to do all the sorting, paging,
filtering, searching etc. The GridView will be databound to a DataSet
fetched from my DAL, which uses a factory pattern based on the Microsoft
DAAB.

Typically, users create a new customer by clicking on a "New" button, or
edit an existing customer simply by clicking on a row in the GridView. Both
of these actions redirect to the customer.aspx page, which works out whether
the user wants to create a new customer or edit an existing one depending on
whether it has been passed a customer identifier or not.

Typically, there will be a Save button which will work out whether to insert
a new record or update an existing one in the same way. Either action, if
successful, will redirect the user back to the customers.aspx page.

The customer.aspx page will often have dropdowns etc - I populate those via
databinding. However, I never databind the actual record itself. Instead, I
fetch it out of the database via my DAL and populate the form objects
manually. There may or may not be a Customers class - that will depend on
various factors, but mainly on how "reusable" the whole concept of a
"customer" needs to be in the particular web application. There's a whole
ream of nonsense spouted about how the world will end if you use ADO.NET
objects (e.g. DataSets, DataReaders etc) directly in your codebehind - OOP
is fundamental to .NET programming, of course, and quite rightly so, but
care needs to be taken not to get anal about it. If you need a class, write
a class - if you don't, then don't...

Similarly, I never use the SqlDataSource objects or the validation controls.
That doesn't mean that I'm against innovation - quite the contrary. Each new
version of the Framework has brought some fantastic stuff with it, e,g,
generics in v2 and LINQ in v3.5, but "new" and "quick" and "easy" don't
always mean "good", IMO...

There will no doubt be people sniggering at this, or throwing their arms up
in disbelief...


--
Mark Rae
ASP.NET MVP
http://www.markrae.net