By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,691 Members | 1,123 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,691 IT Pros & Developers. It's quick & easy.

Standard/Best Practice

P: n/a
I am rebuilding an existing application that relies on an SQL DB. The
app is a scheduling/employee management program. My question pertains
to best practices in dotnet and database.

I use a 3 tier model and have custom classes for things like Employees.
What comes to question is when I load an Employee from my DB, I
populate the properties of the object with the data in the dataset.
When I want to view the employee on a form, i bind the properties to
form elements. To update the employee, I param the employee data and
send it back to the database. If I was using a dataadapter and
dataset, however, it would eliminate a lot of code and time.

Unfortunately this practice eliminates most of the benefits of
datasets, binding, the designer surface, etc. It also forces me to
create a custom collection for even the simplest of objects instead of
passing a dataset to the designer surface and binding it to a datagrid.

Is there a better practice, or should i continue with this course?

Jun 6 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Chrown,

..Net is a environment where you can make things that are for your best
practise. If there was a general best practise than it would be more like
office access in my idea.

Because that the words 3 tier are used at the moment more and more (and seen
on many webpages) for multilayer applications than for real physical 3 tier
applications, can you describe it a little bit more. Because of your
description it can be both.

In my idea is adonet not designed for physical 3 tier applications which can
be easily done than on seperated servers. If it is a datalayer approach,
than it is in version 2005 almost complete incorporated in the strongly
typed datasets (datasources).

If it is version 2002/2003 than mostly just using a component instead of a
form will make the road to the datalayer concept very simple to go.

Just some thoughts, because I am not sure what you are using.

Cor

<cb****@duclaw.com> schreef in bericht
news:11**********************@f6g2000cwb.googlegro ups.com...
I am rebuilding an existing application that relies on an SQL DB. The
app is a scheduling/employee management program. My question pertains
to best practices in dotnet and database.

I use a 3 tier model and have custom classes for things like Employees.
What comes to question is when I load an Employee from my DB, I
populate the properties of the object with the data in the dataset.
When I want to view the employee on a form, i bind the properties to
form elements. To update the employee, I param the employee data and
send it back to the database. If I was using a dataadapter and
dataset, however, it would eliminate a lot of code and time.

Unfortunately this practice eliminates most of the benefits of
datasets, binding, the designer surface, etc. It also forces me to
create a custom collection for even the simplest of objects instead of
passing a dataset to the designer surface and binding it to a datagrid.

Is there a better practice, or should i continue with this course?

Jun 6 '06 #2

P: n/a
My tiers consist of a UI layer, Business Layer, Data access layer.
There is also a data layer which is the SQL Server Database. I am
using dotnet 1.1 on VS 2003. My Data access layer uses Strongly typed
datasets, but these only get used to pull info from to populate
class/object data. My Data acces layer uses components to make use of
the designer features to quickly create dataadapters/readers, however
the VS help ends there when the dataset gets passed to the Business
layer only and doesn't make it to the UI layer.

This model is the previous developers model which I am hoping to make
improve to make development and code management better.
Cor Ligthert [MVP] wrote:
Chrown,

.Net is a environment where you can make things that are for your best
practise. If there was a general best practise than it would be more like
office access in my idea.

Because that the words 3 tier are used at the moment more and more (and seen
on many webpages) for multilayer applications than for real physical 3 tier
applications, can you describe it a little bit more. Because of your
description it can be both.

In my idea is adonet not designed for physical 3 tier applications which can
be easily done than on seperated servers. If it is a datalayer approach,
than it is in version 2005 almost complete incorporated in the strongly
typed datasets (datasources).

If it is version 2002/2003 than mostly just using a component instead of a
form will make the road to the datalayer concept very simple to go.

Just some thoughts, because I am not sure what you are using.

Cor

<cb****@duclaw.com> schreef in bericht
news:11**********************@f6g2000cwb.googlegro ups.com...
I am rebuilding an existing application that relies on an SQL DB. The
app is a scheduling/employee management program. My question pertains
to best practices in dotnet and database.

I use a 3 tier model and have custom classes for things like Employees.
What comes to question is when I load an Employee from my DB, I
populate the properties of the object with the data in the dataset.
When I want to view the employee on a form, i bind the properties to
form elements. To update the employee, I param the employee data and
send it back to the database. If I was using a dataadapter and
dataset, however, it would eliminate a lot of code and time.

Unfortunately this practice eliminates most of the benefits of
datasets, binding, the designer surface, etc. It also forces me to
create a custom collection for even the simplest of objects instead of
passing a dataset to the designer surface and binding it to a datagrid.

Is there a better practice, or should i continue with this course?


Jun 6 '06 #3

P: n/a
cbBrown,

Are you able to have a look at VS 2005. I think that changing now based on
VS2003 is not the wisest to do.

The concept with the tableadapter, the datasources and the new strongly
typed dataset is in my opinion so much changed, that it would be wrong to go
on with the concept of VS 2003.

Maybe can you try an Express version of VS2005.

Just my thought,

Cor

<cb****@duclaw.com> schreef in bericht
news:11**********************@f6g2000cwb.googlegro ups.com...
My tiers consist of a UI layer, Business Layer, Data access layer.
There is also a data layer which is the SQL Server Database. I am
using dotnet 1.1 on VS 2003. My Data access layer uses Strongly typed
datasets, but these only get used to pull info from to populate
class/object data. My Data acces layer uses components to make use of
the designer features to quickly create dataadapters/readers, however
the VS help ends there when the dataset gets passed to the Business
layer only and doesn't make it to the UI layer.

This model is the previous developers model which I am hoping to make
improve to make development and code management better.
Cor Ligthert [MVP] wrote:
Chrown,

.Net is a environment where you can make things that are for your best
practise. If there was a general best practise than it would be more like
office access in my idea.

Because that the words 3 tier are used at the moment more and more (and
seen
on many webpages) for multilayer applications than for real physical 3
tier
applications, can you describe it a little bit more. Because of your
description it can be both.

In my idea is adonet not designed for physical 3 tier applications which
can
be easily done than on seperated servers. If it is a datalayer approach,
than it is in version 2005 almost complete incorporated in the strongly
typed datasets (datasources).

If it is version 2002/2003 than mostly just using a component instead of
a
form will make the road to the datalayer concept very simple to go.

Just some thoughts, because I am not sure what you are using.

Cor

<cb****@duclaw.com> schreef in bericht
news:11**********************@f6g2000cwb.googlegro ups.com...
>I am rebuilding an existing application that relies on an SQL DB. The
> app is a scheduling/employee management program. My question pertains
> to best practices in dotnet and database.
>
> I use a 3 tier model and have custom classes for things like Employees.
> What comes to question is when I load an Employee from my DB, I
> populate the properties of the object with the data in the dataset.
> When I want to view the employee on a form, i bind the properties to
> form elements. To update the employee, I param the employee data and
> send it back to the database. If I was using a dataadapter and
> dataset, however, it would eliminate a lot of code and time.
>
> Unfortunately this practice eliminates most of the benefits of
> datasets, binding, the designer surface, etc. It also forces me to
> create a custom collection for even the simplest of objects instead of
> passing a dataset to the designer surface and binding it to a datagrid.
>
> Is there a better practice, or should i continue with this course?
>

Jun 6 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.