Data binding vs n-tier


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 15 of 15

Thread: Data binding vs n-tier

  1. #1
    Kathleen Dollard Guest

    Re: Data binding vs n-tier

    Jeff,

    > I noticed that Microsoft went through a lot of trouble adding data binding
    > to windows forms, even to the point where we can drag and drop connections
    > and data sets right on to a form. The data grid control _only_ supports

    data
    > binding. What I don't understand is why? In 3-tier or n-tier architecture,
    > only presentation related code goes into the ui. Business rules should

    never
    > be in the ui, let alone data access code. Doesn't this go against

    everything
    > they've been telling us about architecture design? What am I missing?


    It is just that isolated samples rarely give you a sufficiently robust
    picture.

    DataBindings can be to anything. You need a mechanism to cross the
    boundaries in your three tiered application. I find a derived dataset to be
    the best tool for this, but it certainly isn't the only one.

    You neatly box your data access into classes in one tier. This produces
    data, perhaps a derived dataset and updates data. Your middle tier contains
    business logic, and can easily contain data rules that might otherwise drift
    toward the UI. This is because validation can (and in my opinion should)
    take place in data table events, rather than UI events (at least for
    WinForms). You can then bind to the data and still retain control over its
    access.

    That is rather superficial. Is it enough to get you started?

    Hints:
    If you like drag drop, etc. Add a "Component" to your data layer and drag
    drop there. Just be aware that everything you drop gets instantiated with
    the component.

    Strongly typed datasets are great, imo. They give you design time support.
    That is what I further derive

    The "DataSet" option in the Data toolbox for your form allows you a quick
    way to add a strongly typed data set to your form. This then allows design
    time binding

    Design time databinding of a base form and visual inheritance do not mix.
    You will have to set yoru base form databindings in code.

    There are some quirks to databinding. It does work, and I'd suggest asking
    for help quickly when it seems to not be working.

    Kathleen

    "Jeff Pipes" <JeffP622@msn.com> wrote in message
    news:3cc8281c$1@10.1.10.29...
    >
    > I noticed that Microsoft went through a lot of trouble adding data binding
    > to windows forms, even to the point where we can drag and drop connections
    > and data sets right on to a form. The data grid control _only_ supports

    data
    > binding. What I don't understand is why? In 3-tier or n-tier architecture,
    > only presentation related code goes into the ui. Business rules should

    never
    > be in the ui, let alone data access code. Doesn't this go against

    everything
    > they've been telling us about architecture design? What am I missing?
    >
    > -Jeff




  2. #2
    Jeff Pipes Guest

    Data binding vs n-tier


    I noticed that Microsoft went through a lot of trouble adding data binding
    to windows forms, even to the point where we can drag and drop connections
    and data sets right on to a form. The data grid control _only_ supports data
    binding. What I don't understand is why? In 3-tier or n-tier architecture,
    only presentation related code goes into the ui. Business rules should never
    be in the ui, let alone data access code. Doesn't this go against everything
    they've been telling us about architecture design? What am I missing?

    -Jeff

  3. #3
    Scott Hutchinson Guest

    Re: Data binding vs n-tier

    A key thing to keep in mind is that you can bind the UI controls to a
    disconnected DataSet, which is an in-memory cache of the data. Also the
    DataSet class is completely data source agnostic--it doesn't know and
    doesn't care where the data came from (or in other words, it's independent
    of the data layer). In an n-tier design, the parts that DO know about the
    data source (i.e., the Connection, Command, and/or DataAdapter objects)
    should be kept out of the UI/presentation tier. So, this type of data
    binding shouldn't prevent you from implementing a good n-tier architecture.

    If, on the other hand, you bind the UI controls directly to the data source
    using a connected DataReader, which is usually NOT data source agnostic,
    then your concerns are more relevant.

    Scott Hutchinson
    s.c.o.t.t.h.u.t.c.h.i.n.s.o.n@usa.net

    "Jeff Pipes" <JeffP622@msn.com> wrote in message
    news:3cc8281c$1@10.1.10.29...
    >
    > I noticed that Microsoft went through a lot of trouble adding data binding
    > to windows forms, even to the point where we can drag and drop connections
    > and data sets right on to a form. The data grid control _only_ supports

    data
    > binding. What I don't understand is why? In 3-tier or n-tier architecture,
    > only presentation related code goes into the ui. Business rules should

    never
    > be in the ui, let alone data access code. Doesn't this go against

    everything
    > they've been telling us about architecture design? What am I missing?
    >
    > -Jeff




  4. #4
    Patrick Ireland Guest

    Re: Data binding vs n-tier


    Jeff,

    Kathleen gave you good information.
    I have not had the pleasure yet of
    implementing a system using her
    approach, I hope that an opportunity
    presents itself that I might.

    I attack the UI/BR interface a little
    different. I divide the editting of
    a data field into 2 modes. I use the
    terms suitability and compatibility.

    The field must first meet suitability,
    i.e., numbers in numeric fields. This
    class of editing can be can be testing
    not knowing anything about data on a
    database.

    After the fields meet the suitability
    requirement, then I apply the business
    rules. Here the fields, singlely and
    in combination must meet compatibility
    with the database.

    I realize that I can loose the data
    binding of the UI to the database but
    it allows me to isolate the business
    rules including placing them on a
    completely separate machine, a separate
    language like yeek COBOL, etc.

    So as you can see, there is more than
    1 way to skin a cat. Which is more
    correct? Neither, try to use the
    approach that best fits the circumstances.

    Have you missed anything? No, it is
    just a matter of implementation needs.


  5. #5
    Bill Storage Guest

    Re: Data binding vs n-tier


    "Kathleen Dollard" <kathleen@mvps.org> wrote in message
    news:3cc831d8$1@10.1.10.29...
    >
    > You neatly box your data access into classes in one tier. This produces
    > data, perhaps a derived dataset and updates data. Your middle tier

    contains
    > business logic, and can easily contain data rules that might otherwise

    drift
    > toward the UI. This is because validation can (and in my opinion should)
    > take place in data table events, rather than UI events (at least for
    > WinForms). You can then bind to the data and still retain control over its
    > access.
    >


    Kathleen-
    Are you happy with .Net's support for 3-tier dev with binding as you
    describe? I think I'd rather see a cleaner means of putting a bunch of
    DataAdapters on a component in one tier (in one project) and then being able
    to bind to DataSets exposed by that tier in the client project ( a bit like
    the maligned VB6 DateEnvironment). I'd like a wizard to at least add methods
    to the data-provider component based on the datasets and DataAdpater
    instances it houses. Then I'd like the client project's Properties Browser
    to be able to see the provider's datasets for setting up databinding. I've
    played around with automating this myself, but it looks like a fairly large
    task.

    Bill





  6. #6
    Kathleen Dollard Guest

    Re: Data binding vs n-tier

    Bill,

    > Are you happy with .Net's support for 3-tier dev with binding as you
    > describe? I think I'd rather see a cleaner means of putting a bunch of
    > DataAdapters on a component in one tier (in one project) and then being

    able
    > to bind to DataSets exposed by that tier in the client project ( a bit

    like
    > the maligned VB6 DateEnvironment). I'd like a wizard to at least add

    methods
    > to the data-provider component based on the datasets and DataAdpater
    > instances it houses. Then I'd like the client project's Properties Browser
    > to be able to see the provider's datasets for setting up databinding. I've
    > played around with automating this myself, but it looks like a fairly

    large
    > task.


    I am happy that they didn't try to do too much with three tier development
    too quick. They are bound to screw somethings up (command builder for
    example, and IMO, the strongly typed dataset has major flaws) and having to
    roll our own lets us pick and choose. That said, do I hope it will expand
    significantly in the future, and do I hope we won't all have to write
    auto-gen tools, yes and yes. As they do this,I hope it will be far more
    under our control than the strongly typed dataset generation is.

    I am doing things a little differently than what you describe would fit, and
    I guess our collective conciousness finding the smartest way, then
    automating it sounds more reliable than MS dictating a mechanism. That
    dictation, I think, is why things like <=VB6 databinding and the data
    environment failed.

    (FWIW, I have a DLL that is separate from my data access layer that exposes
    strongly typed datasets that have been further derived to add a couple
    things inlcuding a Fill and Update method. The Fill method says "send
    thyeslf to your datalayer" and the UI has no clue of this. It means that the
    specific data layer component is well hidden, and in fact the data might not
    use a data access layer at all (retrieval from local XML cache for off line
    work, for example). When the dataset arrives at the data layer, it figures o
    ut how to fill it.

    Based on this what I'd like, and am in the process of writing, is a wizard
    that takes a stored proc, actually runs it (because my DBA writes hard to
    parse stored procs) and creates datacommands in the data layer, strongly
    typed datasets in the middle tier, and the associated changes to the
    strongly typed dataset and derived extensions, including parameter support.
    It is quite doable, I am just still solidifying exactly what I want before I
    autogen too much code. For example, I am currently losing enthusiasm for
    creating DataAdapters at design time and expect to completely abandon them
    in favor of creating the adapater at run time based on the commands created
    at design time. I am also coming to detest the .NET component surface for
    this puprose more every day and wish that were a simple listview interface
    and that it created, but did not instantiate the items on the surface when
    the "component like thing" was instantiated. Now _that_ is somethng that
    sounds like a large task to me.

    Currently, I am happy enough with what my UI sees, as the entire middle tier
    DLL(s) interface is of interest to it.)

    Looking forward to your further thoughts!
    Kathleen

    "Bill Storage" <storage@bplusmylastname.com> wrote in message
    news:3cc8a3d1@10.1.10.29...
    >
    > "Kathleen Dollard" <kathleen@mvps.org> wrote in message
    > news:3cc831d8$1@10.1.10.29...
    > >
    > > You neatly box your data access into classes in one tier. This produces
    > > data, perhaps a derived dataset and updates data. Your middle tier

    > contains
    > > business logic, and can easily contain data rules that might otherwise

    > drift
    > > toward the UI. This is because validation can (and in my opinion should)
    > > take place in data table events, rather than UI events (at least for
    > > WinForms). You can then bind to the data and still retain control over

    its
    > > access.
    > >

    >
    > Kathleen-
    > Are you happy with .Net's support for 3-tier dev with binding as you
    > describe? I think I'd rather see a cleaner means of putting a bunch of
    > DataAdapters on a component in one tier (in one project) and then being

    able
    > to bind to DataSets exposed by that tier in the client project ( a bit

    like
    > the maligned VB6 DateEnvironment). I'd like a wizard to at least add

    methods
    > to the data-provider component based on the datasets and DataAdpater
    > instances it houses. Then I'd like the client project's Properties Browser
    > to be able to see the provider's datasets for setting up databinding. I've
    > played around with automating this myself, but it looks like a fairly

    large
    > task.
    >
    > Bill
    >
    >
    >
    >




  7. #7
    Bill Storage Guest

    Re: Data binding vs n-tier


    "Kathleen Dollard" <kathleen@mvps.org> wrote in message
    news:3cc98020$1@10.1.10.29...
    > Bill,
    >
    >


    Sounds like your experience and sentiments have been similar to mine. What
    you describe here is very similar to what many of us (sounds like you too)
    were doing with VB6/ADO - codegen of command objects, etc. I'll put together
    some more coherent thoughts and get back to you.

    Bill



  8. #8
    Jeff Pipes Guest

    Re: Data binding vs n-tier


    Ok, let me re-phrase my original question. Yes, you can databind to regular
    classes and still keep your data access in a separate tier. But what about
    dragging and dropping actual connections on to your form and accessing your
    data from there? Isn't that a violation of 3-tier architecture?

    -Jeff


    "Kathleen Dollard" <kathleen@mvps.org> wrote:
    >Jeff,
    >
    >> I noticed that Microsoft went through a lot of trouble adding data binding
    >> to windows forms, even to the point where we can drag and drop connections
    >> and data sets right on to a form. The data grid control _only_ supports

    >data
    >> binding. What I don't understand is why? In 3-tier or n-tier architecture,
    >> only presentation related code goes into the ui. Business rules should

    >never
    >> be in the ui, let alone data access code. Doesn't this go against

    >everything
    >> they've been telling us about architecture design? What am I missing?

    >
    >It is just that isolated samples rarely give you a sufficiently robust
    >picture.
    >
    >DataBindings can be to anything. You need a mechanism to cross the
    >boundaries in your three tiered application. I find a derived dataset to

    be
    >the best tool for this, but it certainly isn't the only one.
    >
    >You neatly box your data access into classes in one tier. This produces
    >data, perhaps a derived dataset and updates data. Your middle tier contains
    >business logic, and can easily contain data rules that might otherwise drift
    >toward the UI. This is because validation can (and in my opinion should)
    >take place in data table events, rather than UI events (at least for
    >WinForms). You can then bind to the data and still retain control over its
    >access.
    >
    >That is rather superficial. Is it enough to get you started?
    >
    >Hints:
    >If you like drag drop, etc. Add a "Component" to your data layer and drag
    >drop there. Just be aware that everything you drop gets instantiated with
    >the component.
    >
    >Strongly typed datasets are great, imo. They give you design time support.
    >That is what I further derive
    >
    >The "DataSet" option in the Data toolbox for your form allows you a quick
    >way to add a strongly typed data set to your form. This then allows design
    >time binding
    >
    >Design time databinding of a base form and visual inheritance do not mix.
    >You will have to set yoru base form databindings in code.
    >
    >There are some quirks to databinding. It does work, and I'd suggest asking
    >for help quickly when it seems to not be working.
    >
    >Kathleen



  9. #9
    Jeff Pipes Guest

    Re: Data binding vs n-tier


    "Kathleen Dollard" <kathleen@mvps.org> wrote:
    >the strongly typed dataset has major flaws


    How so? Sorry to ask so many questions but I'm still new to this.

    -Jeff



  10. #10
    Jeff Pipes Guest

    Re: Data binding vs n-tier


    Whenever I see someone give a demostration of ado.net, they're always dragging
    and dropping connections, tables, etc right on to the design surface of the
    form. And I think to myself what happened to 3-tier?

    -Jeff

    "Scott Hutchinson" <scotthutchinson@usa.net> wrote:
    >A key thing to keep in mind is that you can bind the UI controls to a
    >disconnected DataSet, which is an in-memory cache of the data. Also the
    >DataSet class is completely data source agnostic--it doesn't know and
    >doesn't care where the data came from (or in other words, it's independent
    >of the data layer). In an n-tier design, the parts that DO know about the
    >data source (i.e., the Connection, Command, and/or DataAdapter objects)
    >should be kept out of the UI/presentation tier. So, this type of data
    >binding shouldn't prevent you from implementing a good n-tier architecture.
    >
    >If, on the other hand, you bind the UI controls directly to the data source
    >using a connected DataReader, which is usually NOT data source agnostic,
    >then your concerns are more relevant.
    >
    >Scott Hutchinson
    >s.c.o.t.t.h.u.t.c.h.i.n.s.o.n@usa.net
    >
    >"Jeff Pipes" <JeffP622@msn.com> wrote in message
    >news:3cc8281c$1@10.1.10.29...
    >>
    >> I noticed that Microsoft went through a lot of trouble adding data binding
    >> to windows forms, even to the point where we can drag and drop connections
    >> and data sets right on to a form. The data grid control _only_ supports

    >data
    >> binding. What I don't understand is why? In 3-tier or n-tier architecture,
    >> only presentation related code goes into the ui. Business rules should

    >never
    >> be in the ui, let alone data access code. Doesn't this go against

    >everything
    >> they've been telling us about architecture design? What am I missing?
    >>
    >> -Jeff

    >
    >



  11. #11
    Kathleen Dollard Guest

    Re: Data binding vs n-tier

    Jeff,

    > Ok, let me re-phrase my original question. Yes, you can databind to

    regular
    > classes and still keep your data access in a separate tier. But what about
    > dragging and dropping actual connections on to your form and accessing

    your
    > data from there? Isn't that a violation of 3-tier architecture?


    Yes, avoid putting connections or adapters on your form. It limits reuse,
    devestates 3-tier design and is entirely unnecessary.

    Kathleen



  12. #12
    Kathleen Dollard Guest

    Re: Data binding vs n-tier

    Jeff,

    > >the strongly typed dataset has major flaws

    >
    > How so? Sorry to ask so many questions but I'm still new to this.


    You have to take that in the context it was stated. Bill asked whether I was
    happy with .NET's support for 3-tier architecture. In the context of whether
    I am happy, yes it has flaws.

    The major problem is you have to change the strongly typed dataset (which
    means your changes are overwritten so you have to do this a lot) to
    instantiate derived strongly typed DataTables. The primary reason you might
    want to do this is to handle the ColumnUpdating, etc events right in the
    DataTable, but there are some other reasons. Also, the handling of nulls is
    not flexible enough, imo (you don't have an option to use the SQLtypes). You
    also don't have much flexibility in whether particular methods, such as that
    AddNew with all of the field data, are included. Strongly typed datasets
    really need to support Enums for properties, although I haven't quite
    figured out a good way to define that.

    I hope we will move toward more of a template driven system where different
    architectures can be easily created via autogenned code.

    Kathleen




  13. #13
    Alex Rosen Guest

    Re: Data binding vs n-tier

    > The major problem is you have to change the strongly typed dataset (which
    > means your changes are overwritten so you have to do this a lot) to
    > instantiate derived strongly typed DataTables. The primary reason you

    might
    > want to do this is to handle the ColumnUpdating, etc events right in the
    > DataTable, but there are some other reasons. Also, the handling of nulls

    is
    > not flexible enough, imo (you don't have an option to use the SQLtypes).

    You
    > also don't have much flexibility in whether particular methods, such as

    that
    > AddNew with all of the field data, are included. Strongly typed datasets
    > really need to support Enums for properties, although I haven't quite
    > figured out a good way to define that.


    I think a major problem with strongly-typed DataSets is the number of
    different ways they can be produced and the different results you get from
    each technique. This overly complicates the learning curve imo. I took some
    notes as I went up that curve and include them below to hopefully help
    others avoid some pain. Before the notes though I will also add that it
    would be nice if there was a way to automatically generate them with the
    table relationships (maybe there is -- I guess I didn't try hard on this). I
    manually add the relationships using the XML designer after the xsd is
    generated. I also add my own annotations which is a nice feature but is not
    automated at all. I keep the lines I add in a file for manual copy/paste
    after every re-gen at the moment but will automate this some day.

    Finally, I'm not sure I agree with where you are going with adding more
    logic into the strongly-typed DataSets. I see them as a Data Transfer
    Objects (http://www.martinfowler.com/isa/dataTransferObject.html). They
    already have a lot of general purpose data manipulation logic (sorting,
    filtering, adding, removing) and validation logic (type, length,
    nullability). I guess I'm not clear on whether you are advocating extending
    the strongly-typed DataSet to turn it into a middle tier component or if you
    are mainly using it for passing data. If you are turning them into the
    business logic components that sounds like a reasonable approach. If you are
    talking about using them for passing data but also adding more logic then I
    feel like there is a problem because the business logic is getting spread
    out and would be more difficult to maintain. My approach is to only add
    general purpose functionality or things that deal with straightforward
    representation and enforcement of the data structure to the DataSets I
    create. Any more complex rules go in business logic components that process
    DataSets. I kind of wish MS would give some guidance on these principles so
    we would have some type of standard. There are too many ways of doing things
    and I would like to just work with a set of patterns that work reasonably
    well and are well worn by the community.

    OK... Here are those notes...

    Strongly-typed DataSets can be generated in at least four ways:

    1. Populate a DataSet with a sample of the data you wish to represent in the
    Dataset and then use the DataSet's WriteXMLSchema method to generate the xsd
    file. Finally, use the xsd tool to generate a class based on the schema. The
    problem with this method is that important information about keys,
    nullability, and maximum lengths of fields is not included in the xsd file
    and therefore is also missing from the class.

    2. Add a new DataSet item to the project and then drag a table onto the
    design surface. This method generates an xsd that includes more information
    than the previous approach but still lacks the maximum length information.

    3. Add a DataAdapter to a form and then choose the Generate DataSets link
    from the bottom of the properties window. This yields the same results as
    #2.

    4. Use the FillSchema method of the DataAdapter to generate the xsd. This
    method includes the most information about the DataSet. Here is a code
    excerpt that works with a previously opened connection:

    ' Set up a data adapter object.
    Dim strSelect As String = "SELECT * FROM VMUser"
    Dim da As New SqlDataAdapter(strSelect, cn)
    ' Load a data set.
    Dim ds As New DataSet("VMUserDataSet")
    da.FillSchema(ds, SchemaType.Source)

    The WriteXMLSchema method of the DataSet is then used to generate the xsd
    file.

    The strongly-type DataSets are more standard, provide a nicer coding style
    and better Intellisense support. However, they are harder to comprehend and
    definitely more of a hassle to maintain as any change in the database schema
    requires regeneration of the class. Nevertheless, after researching it and
    learning about technique number 4 I now think the application should use
    strongly-typed DataSets. The biggest headache is regenerating them when
    changes are made to the database schema. Before switching the app to the new
    way, code needs to be developed to regenerate each DataSet type in use to
    reduce maintenance time. The code should dynamically determine the project's
    location and regenerate the xsd file over the existing one in the project.
    To (re)generate the DataSet class file you need to set the Custom Tool
    property of the XSD file to MSDataSetGenerator. Simply setting the property
    seems to cause the tool to be run. It may be run again by right clicking on
    the XSD file and selecting "Run Custom Tool".




  14. #14
    Kathleen Dollard Guest

    Re: Data binding vs n-tier

    Alex,

    I have recently been workign with code driven methods to build the XSD so
    appreciate your comments. My main reason was to snag the relations. I am
    still working on getting my macros to modify the dumb strongly typed dataset
    completed. On this project I want to be able to inherit from the strongly
    typed tables so that validation events are handled in the table, not the
    dataset. While it is not in the XSD, I believe that the size is in the
    resulting datacolumns if you fill the dataset using AddWithPrimaryKey.

    > Finally, I'm not sure I agree with where you are going with adding more
    > logic into the strongly-typed DataSets. I see them as a Data Transfer
    > Objects (http://www.martinfowler.com/isa/dataTransferObject.html). They
    > already have a lot of general purpose data manipulation logic (sorting,
    > filtering, adding, removing) and validation logic (type, length,
    > nullability). I guess I'm not clear on whether you are advocating

    extending
    > the strongly-typed DataSet to turn it into a middle tier component or if

    you
    > are mainly using it for passing data. If you are turning them into the
    > business logic components that sounds like a reasonable approach. If you

    are
    > talking about using them for passing data but also adding more logic then

    I
    > feel like there is a problem because the business logic is getting spread
    > out and would be more difficult to maintain.


    I didn't follow your distinction between turning them in to business logic
    components and not. We don't have much business logic outside the database
    except for validation rules that apply to single fields. Therefore, I think
    it entirely appropriate to keep it as close to the data as possible. Where
    there is a lot of true business logic, I think you need a separate set of
    classes, and that those classes may not parallel the data tables closely. So
    perhaps we agree, I am not sure.

    Kathleen



  15. #15
    Alex Rosen Guest

    Re: Data binding vs n-tier

    > On this project I want to be able to inherit from the strongly
    > typed tables so that validation events are handled in the table, not the
    > dataset.


    Got ya.

    > While it is not in the XSD, I believe that the size is in the
    > resulting datacolumns if you fill the dataset using AddWithPrimaryKey.


    I'll have to check out that option. I did correspond with MS on this issue
    and someone there told me they left out that information I mentioned because
    it made the XSD ugly in the designer. Sounded odd to me. They suggested the
    4th method which is what I have adopted but if adding this option works
    maybe I'll switch back.

    > I didn't follow your distinction between turning them in to business logic
    > components and not. We don't have much business logic outside the database
    > except for validation rules that apply to single fields. Therefore, I

    think
    > it entirely appropriate to keep it as close to the data as possible. Where
    > there is a lot of true business logic, I think you need a separate set of
    > classes, and that those classes may not parallel the data tables closely.

    So
    > perhaps we agree, I am not sure.


    I see what you are saying and that architecture makes sense to me for the
    kind of app you described. I am building an app without much true business
    logic as well but I am putting what logic there is into the separate
    classes. Maybe it is over-engineering but I am trying to follow what I think
    MS was proposing in their enterprise application samples. Sad thing is I
    found problems with those samples after I started down the path so now I
    have somewhat of a mish mash that I am slowly making more uniform as I
    learn. Good thing this app is internal and I'll be able to play with it
    later. I don't see much guidance anywhere about how to handle the biz logic.
    I agree for simple validation stuff you can just put it in overrides of the
    code generated by the strongly-typed DataSet tool. When we get into more
    complex stuff I have tried to follow the Facade Layer/Business Rules layer
    approach MS uses in their samples. I have run into some mental roadblocks
    though. I am going to try to put together what the issues I have hit are in
    a separate thread (maybe in a few days) so I can get feedback from the
    group. Like others, I have been reading and practicing but I haven't hit an
    approach that seems ideal.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center