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
"Ryan" <Tyveil@newsgroups.nospam> wrote in message
news:OIRCdKvlGHA.4512@TK2MSFTNGP04.phx.gbl...[color=blue]
> Paul,
>
> Thanks for the very informative post. I'm beginning to see the light I
> think ;)
>[color=green]
>> "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.[/color]
>
> 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.
>[color=green]
>> 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...[/color]
>
> 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" <noone@nowhere.net> wrote in message
> news:etov%23YulGHA.3632@TK2MSFTNGP03.phx.gbl...[color=green]
>>- 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...[color=darkred]
>>> 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" <noone@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/lib...59(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
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]
