"Ryan" <Tyveil@newsgroups.nospam> wrote in message
news:%23toFE6slGHA.2180@TK2MSFTNGP05.phx.gbl...
> I'm in the process of learning more about building my ASP.NET website to
> use my SQL datastore and am a bit confused about how ADO.NET works with
> ASP.NET. This Microsoft article implies that using ADO.NET with ASP.NET
> applications is the way of the past because newer controls allow you to do
> all your data binding declaratively.
> http://msdn2.microsoft.com/en-us/library/ms178359(d=ide).aspx
>
> However, I haven't been able to get my application to work just using
> these controls.  There is a lot of complex dataprocessing that needs to be
> done with code.  For example, once a user completes filling out a resume
> form I need to create a new item in the resume table, using the new
> resumeid I then need to add rows to multiple tables (lets just say these
> resume forms are pretty complex, the questions are created dynamically by
> backend users and each form is related to positions they're applying for,
> the dynamic question table, etc).  So anyways, to cut a long story short,
> I'm thinking using ADO.NET Datasets and Datatables is the way to go.  I've
> done pretty well using these features with my backend application (a
> Windows project using Windows forms - not ASP.NET), but for the ASP.NET
> website user end I'm missing the Data Sources window and the easy
> drag-drop capabilities of creating and managing Datasets (including the
> Dataset designer).  Is Microsoft trying to discourage me from using
> Datasets with ASP.NET?  What should I be using to code the database
> queries?  SQLdatasource is nice but I'm finding it hard to use
> programmatically.  It works nice to bind to controls but that seems to be
> the only way it is usable.
>
> Thanks for any advice.
> Ryan
>

"PJ6" <no***@nowhere.net> wrote in message
news:eBoYkstlGHA.4212@TK2MSFTNGP03.phx.gbl...
> This is probably a good example of where you want to compile your business
> layer in a separate dll, and have that support both the thin and thick
> clients. Ideally your UI layers shouldn't care at all about the details of
> data access - that means they won't see data sets.
>
> Also, you may want to think about moving away from data binding - raw SQL,
> even if it's automatically generated for you, does not belong in compiled
> code. Any data access details that you do have in code, such as column
> name mapping  to particualr object fields, should be kept non-declarative
> (i.e. attributes).
>
> Paul
>
> "Ryan" <Tyveil@newsgroups.nospam> wrote in message
> news:%23toFE6slGHA.2180@TK2MSFTNGP05.phx.gbl...
>> I'm in the process of learning more about building my ASP.NET website to
>> use my SQL datastore and am a bit confused about how ADO.NET works with
>> ASP.NET. This Microsoft article implies that using ADO.NET with ASP.NET
>> applications is the way of the past because newer controls allow you to
>> do all your data binding declaratively.
>> http://msdn2.microsoft.com/en-us/library/ms178359(d=ide).aspx
>>
>> However, I haven't been able to get my application to work just using
>> these controls.  There is a lot of complex dataprocessing that needs to
>> be done with code.  For example, once a user completes filling out a
>> resume form I need to create a new item in the resume table, using the
>> new resumeid I then need to add rows to multiple tables (lets just say
>> these resume forms are pretty complex, the questions are created
>> dynamically by backend users and each form is related to positions
>> they're applying for, the dynamic question table, etc).  So anyways, to
>> cut a long story short, I'm thinking using ADO.NET Datasets and
>> Datatables is the way to go.  I've done pretty well using these features
>> with my backend application (a Windows project using Windows forms - not
>> ASP.NET), but for the ASP.NET website user end I'm missing the Data
>> Sources window and the easy drag-drop capabilities of creating and
>> managing Datasets (including the Dataset designer).  Is Microsoft trying
>> to discourage me from using Datasets with ASP.NET?  What should I be
>> using to code the database queries?  SQLdatasource is nice but I'm
>> finding it hard to use programmatically.  It works nice to bind to
>> controls but that seems to be the only way it is usable.
>>
>> Thanks for any advice.
>> Ryan
>>
>
>

"Ryan" <Tyveil@newsgroups.nospam> wrote in message
news:%23E6%230xtlGHA.1640@TK2MSFTNGP02.phx.gbl...
> So I should do all my processing using SQL functions, etc stored on the
> SQL server?  Can you elaborate on what you mean by attributes (private
> member variables of the form?)?  Move away from data binding?  Why did
> Microsoft implement all these new databinding features if I'm not suppose
> to use them? :)
>
> Thanks,
> Ryan
>
> "PJ6" <no***@nowhere.net> wrote in message
> news:eBoYkstlGHA.4212@TK2MSFTNGP03.phx.gbl...
>> This is probably a good example of where you want to compile your
>> business layer in a separate dll, and have that support both the thin and
>> thick clients. Ideally your UI layers shouldn't care at all about the
>> details of data access - that means they won't see data sets.
>>
>> Also, you may want to think about moving away from data binding - raw
>> SQL, even if it's automatically generated for you, does not belong in
>> compiled code. Any data access details that you do have in code, such as
>> column name mapping  to particualr object fields, should be kept
>> non-declarative (i.e. attributes).
>>
>> Paul
>>
>> "Ryan" <Tyveil@newsgroups.nospam> wrote in message
>> news:%23toFE6slGHA.2180@TK2MSFTNGP05.phx.gbl...
>>> I'm in the process of learning more about building my ASP.NET website to
>>> use my SQL datastore and am a bit confused about how ADO.NET works with
>>> ASP.NET. This Microsoft article implies that using ADO.NET with ASP.NET
>>> applications is the way of the past because newer controls allow you to
>>> do all your data binding declaratively.
>>> http://msdn2.microsoft.com/en-us/library/ms178359(d=ide).aspx
>>>
>>> However, I haven't been able to get my application to work just using
>>> these controls.  There is a lot of complex dataprocessing that needs to
>>> be done with code.  For example, once a user completes filling out a
>>> resume form I need to create a new item in the resume table, using the
>>> new resumeid I then need to add rows to multiple tables (lets just say
>>> these resume forms are pretty complex, the questions are created
>>> dynamically by backend users and each form is related to positions
>>> they're applying for, the dynamic question table, etc).  So anyways, to
>>> cut a long story short, I'm thinking using ADO.NET Datasets and
>>> Datatables is the way to go.  I've done pretty well using these features
>>> with my backend application (a Windows project using Windows forms - not
>>> ASP.NET), but for the ASP.NET website user end I'm missing the Data
>>> Sources window and the easy drag-drop capabilities of creating and
>>> managing Datasets (including the Dataset designer).  Is Microsoft trying
>>> to discourage me from using Datasets with ASP.NET?  What should I be
>>> using to code the database queries?  SQLdatasource is nice but I'm
>>> finding it hard to use programmatically.  It works nice to bind to
>>> controls but that seems to be the only way it is usable.
>>>
>>> Thanks for any advice.
>>> Ryan
>>>
>>
>>
>
>

"PJ6" <no***@nowhere.net> wrote in message
news:etov%23YulGHA.3632@TK2MSFTNGP03.phx.gbl...
>- So I should do all my processing using SQL functions, etc stored on the
>SQL server?
>
> "All processing"? I don't know what you mean by that. But if you mean all
> data set manipulation and retrieval, such as selecting from one or more
> tables and picking out the rows and columns you want for a particular view
> of data, all this information belongs in stored procedures.
>
> - Can you elaborate on what you mean by attributes (private member
> variables of the form?)?
>
> A good business layer design pattern is to use attributes to store data
> mapping information. So if I want to generate a collection of a particular
> object of type "Car" from a data table...
>
> Public Class Car
>
>   <MapToColumn("Color")> _
>    Protected _Color as String
>
>    Public Readonly Property Color as String
>        Get
>            Return _Color
>        End Get
>    End Property
>
> End Class
>
> it's easy to generalize populating the fields from a particular result set
> by
>
> 1. Creating a new object (in this case, Car) for each row
> 2. Cycling through each data column in the result set, and matching them
> up with and setting the contents of each attributed field
>
> Doing it this way can completely eliminate the need to have code that
> specifically mentions each field to populate it. You also (should you ever
> have the need) now have the ability to reliably collect data mapping
> information in your entire application when it comes time to change the
> database.
>
> - Move away from data binding?  Why did Microsoft implement all these new
> databinding features if I'm not suppose to use them?
>
> Some features or products Microsoft gives developers to use (such as
> Access) may be designed for the lowest common denominator of programmer,
> someone who is just getting into development and needs an "easy" way into
> it. Easy is fine, but it has been my experience that these entry points do
> not foster good practice or proper architecture - or proper learning, for
> that matter. As an instructor, I've often had to back people up that
> thought they knew data access and retrain them, because data binding is
> all they knew.
>
> Paul
>
> "Ryan" <Tyveil@newsgroups.nospam> wrote in message
> news:%23E6%230xtlGHA.1640@TK2MSFTNGP02.phx.gbl...
>> So I should do all my processing using SQL functions, etc stored on the
>> SQL server?  Can you elaborate on what you mean by attributes (private
>> member variables of the form?)?  Move away from data binding?  Why did
>> Microsoft implement all these new databinding features if I'm not suppose
>> to use them? :)
>>
>> Thanks,
>> Ryan
>>
>> "PJ6" <no***@nowhere.net> wrote in message
>> news:eBoYkstlGHA.4212@TK2MSFTNGP03.phx.gbl...
>>> This is probably a good example of where you want to compile your
>>> business layer in a separate dll, and have that support both the thin
>>> and thick clients. Ideally your UI layers shouldn't care at all about
>>> the details of data access - that means they won't see data sets.
>>>
>>> Also, you may want to think about moving away from data binding - raw
>>> SQL, even if it's automatically generated for you, does not belong in
>>> compiled code. Any data access details that you do have in code, such as
>>> column name mapping  to particualr object fields, should be kept
>>> non-declarative (i.e. attributes).
>>>
>>> Paul
>>>
>>> "Ryan" <Tyveil@newsgroups.nospam> wrote in message
>>> news:%23toFE6slGHA.2180@TK2MSFTNGP05.phx.gbl...
>>>> I'm in the process of learning more about building my ASP.NET website
>>>> to use my SQL datastore and am a bit confused about how ADO.NET works
>>>> with ASP.NET. This Microsoft article implies that using ADO.NET with
>>>> ASP.NET applications is the way of the past because newer controls
>>>> allow you to do all your data binding declaratively.
>>>> http://msdn2.microsoft.com/en-us/library/ms178359(d=ide).aspx
>>>>
>>>> However, I haven't been able to get my application to work just using
>>>> these controls.  There is a lot of complex dataprocessing that needs to
>>>> be done with code.  For example, once a user completes filling out a
>>>> resume form I need to create a new item in the resume table, using the
>>>> new resumeid I then need to add rows to multiple tables (lets just say
>>>> these resume forms are pretty complex, the questions are created
>>>> dynamically by backend users and each form is related to positions
>>>> they're applying for, the dynamic question table, etc).  So anyways, to
>>>> cut a long story short, I'm thinking using ADO.NET Datasets and
>>>> Datatables is the way to go.  I've done pretty well using these
>>>> features with my backend application (a Windows project using Windows
>>>> forms - not ASP.NET), but for the ASP.NET website user end I'm missing
>>>> the Data Sources window and the easy drag-drop capabilities of creating
>>>> and managing Datasets (including the Dataset designer).  Is Microsoft
>>>> trying to discourage me from using Datasets with ASP.NET?  What should
>>>> I be using to code the database queries?  SQLdatasource is nice but I'm
>>>> finding it hard to use programmatically.  It works nice to bind to
>>>> controls but that seems to be the only way it is usable.
>>>>
>>>> Thanks for any advice.
>>>> Ryan
>>>>
>>>
>>>
>>
>>
>
>

"Ryan" <Tyveil@newsgroups.nospam> wrote in message
news:OIRCdKvlGHA.4512@TK2MSFTNGP04.phx.gbl...
> Paul,
>
> Thanks for the very informative post.  I'm beginning to see the light I
> think ;)
>
>> "All processing"? I don't know what you mean by that. But if you mean all
>> data set manipulation and retrieval, such as selecting from one or more
>> tables and picking out the rows and columns you want for a particular
>> view of data, all this information belongs in stored procedures.
>
> Yes by "all processing" I was referring to all my data set manipulation
> and retrieval.  I'd be glad to move all this to stored procedures on the
> SQL server and am definitely more comfortable with that than hardcoding
> everything in VB.  Thanks for the recommendation.
>
>> A good business layer design pattern is to use attributes to store data
>> mapping information. So if I want to generate a collection of a
>> particular object of type "Car" from a data table...
>
> I'm new to this using attributes for data mapping information.  But I'm
> not new to OOP with classes so I think I can catch on pretty quick.  If
> you have any "recommended reading" I'd be glad to hear about any of it,
> otherwise I'll be browsing the help and MSDN online files.
>
> Thanks again,
> Ryan
>
>
> "PJ6" <no***@nowhere.net> wrote in message
> news:etov%23YulGHA.3632@TK2MSFTNGP03.phx.gbl...
>>- So I should do all my processing using SQL functions, etc stored on the
>>SQL server?
>>
>> "All processing"? I don't know what you mean by that. But if you mean all
>> data set manipulation and retrieval, such as selecting from one or more
>> tables and picking out the rows and columns you want for a particular
>> view of data, all this information belongs in stored procedures.
>>
>> - Can you elaborate on what you mean by attributes (private member
>> variables of the form?)?
>>
>> A good business layer design pattern is to use attributes to store data
>> mapping information. So if I want to generate a collection of a
>> particular object of type "Car" from a data table...
>>
>> Public Class Car
>>
>>   <MapToColumn("Color")> _
>>    Protected _Color as String
>>
>>    Public Readonly Property Color as String
>>        Get
>>            Return _Color
>>        End Get
>>    End Property
>>
>> End Class
>>
>> it's easy to generalize populating the fields from a particular result
>> set by
>>
>> 1. Creating a new object (in this case, Car) for each row
>> 2. Cycling through each data column in the result set, and matching them
>> up with and setting the contents of each attributed field
>>
>> Doing it this way can completely eliminate the need to have code that
>> specifically mentions each field to populate it. You also (should you
>> ever have the need) now have the ability to reliably collect data mapping
>> information in your entire application when it comes time to change the
>> database.
>>
>> - Move away from data binding?  Why did Microsoft implement all these new
>> databinding features if I'm not suppose to use them?
>>
>> Some features or products Microsoft gives developers to use (such as
>> Access) may be designed for the lowest common denominator of programmer,
>> someone who is just getting into development and needs an "easy" way into
>> it. Easy is fine, but it has been my experience that these entry points
>> do not foster good practice or proper architecture - or proper learning,
>> for that matter. As an instructor, I've often had to back people up that
>> thought they knew data access and retrain them, because data binding is
>> all they knew.
>>
>> Paul
>>
>> "Ryan" <Tyveil@newsgroups.nospam> wrote in message
>> news:%23E6%230xtlGHA.1640@TK2MSFTNGP02.phx.gbl...
>>> So I should do all my processing using SQL functions, etc stored on the
>>> SQL server?  Can you elaborate on what you mean by attributes (private
>>> member variables of the form?)?  Move away from data binding?  Why did
>>> Microsoft implement all these new databinding features if I'm not
>>> suppose to use them? :)
>>>
>>> Thanks,
>>> Ryan
>>>
>>> "PJ6" <no***@nowhere.net> wrote in message
>>> news:eBoYkstlGHA.4212@TK2MSFTNGP03.phx.gbl...
>>>> This is probably a good example of where you want to compile your
>>>> business layer in a separate dll, and have that support both the thin
>>>> and thick clients. Ideally your UI layers shouldn't care at all about
>>>> the details of data access - that means they won't see data sets.
>>>>
>>>> Also, you may want to think about moving away from data binding - raw
>>>> SQL, even if it's automatically generated for you, does not belong in
>>>> compiled code. Any data access details that you do have in code, such
>>>> as column name mapping  to particualr object fields, should be kept
>>>> non-declarative (i.e. attributes).
>>>>
>>>> Paul
>>>>
>>>> "Ryan" <Tyveil@newsgroups.nospam> wrote in message
>>>> news:%23toFE6slGHA.2180@TK2MSFTNGP05.phx.gbl...
>>>>> I'm in the process of learning more about building my ASP.NET website
>>>>> to use my SQL datastore and am a bit confused about how ADO.NET works
>>>>> with ASP.NET. This Microsoft article implies that using ADO.NET with
>>>>> ASP.NET applications is the way of the past because newer controls
>>>>> allow you to do all your data binding declaratively.
>>>>> http://msdn2.microsoft.com/en-us/library/ms178359(d=ide).aspx
>>>>>
>>>>> However, I haven't been able to get my application to work just using
>>>>> these controls.  There is a lot of complex dataprocessing that needs
>>>>> to be done with code.  For example, once a user completes filling out
>>>>> a resume form I need to create a new item in the resume table, using
>>>>> the new resumeid I then need to add rows to multiple tables (lets just
>>>>> say these resume forms are pretty complex, the questions are created
>>>>> dynamically by backend users and each form is related to positions
>>>>> they're applying for, the dynamic question table, etc).  So anyways,
>>>>> to cut a long story short, I'm thinking using ADO.NET Datasets and
>>>>> Datatables is the way to go.  I've done pretty well using these
>>>>> features with my backend application (a Windows project using Windows
>>>>> forms - not ASP.NET), but for the ASP.NET website user end I'm missing
>>>>> the Data Sources window and the easy drag-drop capabilities of
>>>>> creating and managing Datasets (including the Dataset designer).  Is
>>>>> Microsoft trying to discourage me from using Datasets with ASP.NET?
>>>>> What should I be using to code the database queries?  SQLdatasource is
>>>>> nice but I'm finding it hard to use programmatically.  It works nice
>>>>> to bind to controls but that seems to be the only way it is usable.
>>>>>
>>>>> Thanks for any advice.
>>>>> Ryan
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"Ryan" <Tyveil@newsgroups.nospam> wrote in message
news:evfw7fwlGHA.3752@TK2MSFTNGP02.phx.gbl...
> Paul where do you teach?  I think I need to come take your class. ;)  I'm
> just not finding any information on using attributes to map data.
>
> Ryan