Results 1 to 6 of 6
  1. #1
    Join Date
    Aug 2008
    Posts
    58

    Unanswered: OOP Fun with a Client/Server Project

    Hello all,

    Been a while since I've been to this forum. I've got a scenario that I'd like to run by the experts here and see if it's reasonable. I'm developing a database program for company work history (all the projects we've done, who they were for, which staff members worked on them, etc.) to assist proposal development. It's using an SQL Server back-end and an Access front-end with class modules to encapsulate all data access activity. That's straightforward enough, but implementing it in the user interface poses some questions.

    Basically, every entity in the database has it's own data access class. Each entity also has two forms, a "browse" form and an "edit" pop-up form. The browse form allows the user to browse through all of the records in a table (with filtering capability). The edit form is a pop-up form that allows the user to add or update a single record (though the user can add multiple records in the same instance of the edit form).

    So my question is, how should the browse form interact with the edit form? The user will select a single record in the browse form and then click either an "add" or "edit" button to open the edit form. The edit form then must be able to update or add records somehow.

    These are the options I see. None of the data access classes have been written yet. Different options may require a different structure of classes.

    1. Use the same object for both forms. Have the browse form pass a pointer to the edit form. Then the edit form is in control, and can do whatever it needs to with the data.

    2. Use different objects for each form. This would allow the browse form's object to access data with a read-only cursor, which might offer performance benefits. The down side is that both objects would be open (and accessing data) at the same time. I'd basically have two copies of the same table open on the client.

    3. Use a custom collection object for the browse form, and a single object for the edit form. The browse form would pass a single object to the edit form. This has the same issue as option 2, but at least the edit form would only have one record open on the client at any one time.

    4. Keep all object management in the browse form, and use custom properties to return data from the edit form. This is nice for simple entities, but not so nice for complex entities where a single edit form displays data from multiple related tables (e.g., Projects and Project Descriptions).

    Sorry for the long post, but as you can see I've got a lot of questions to answer before this project can really get off the ground.

    And just in case you're thinking "If you're going to all this trouble, why not just code your forms in VB.NET?", it's because we really need reporting functionality with this program. The majority of the user's time will be spent running "searches" to return narratives based on a project's attributes, and Access reports provide a convenient way to display the results of the search (along with related information). If there's a way to make that happen in the VB.NET arena without using a program like Crystal Reports, I'm all ears.

    Thanks!

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Quote Originally Posted by JManSF View Post
    I'm developing a database program... It's using an SQL Server back-end and an Access front-end with class modules to encapsulate all data access activity.

    Basically, every entity in the database has it's own data access class. Each entity also has two forms, a "browse" form and an "edit" pop-up form.*1


    The edit form then must be able to update or add records somehow. These are the options I see...

    3. Use a custom collection object for the browse form, and a single object for the edit form.*2

    you're thinking "If you're going to all this trouble, why not just code your forms in C#*3

    we really need reporting functionality...
    If there's a way to make that happen in the VB.NET arena without using a program like Crystal Reports...*4
    *1:
    What you're talking about pretty much demands a separation between presentation and content. When you're talking about database entities, it will cause fewer headaches if you don't also involve the presentation objects in that conversation.

    *2:
    Again, you're talking about a fairly textbook n-tiered approach in which you have your database, a data access class, some business objects, and a way to look at/manipuate those business objects. With this approach, the standard way of doing things is to have a class that represents a single object, and then create a separate class (or use generics if they're available, List<of T>) to deal with collections of your single objects. Assuming the overhead of this approach is indeed justified by your business requirements, I would suggest sticking relatively close to the best patterns and practices model of having your "view" form consume a custom collection of your objects, and having your "edit" form work with a single custom business object.

    *3:
    Sorry, couldn't resist.

    *4:
    Access is a program like Crystal Reports, so I'm not sure where you're going with this one. They both revolve around the idea of banded reports with section headers and footers. What is it you don't like about Crystal specifically, other than obnoxious licensing? I would recommend looking at SSRS if it's available and you have SQL 2005+.
    Last edited by Teddy; 11-25-09 at 19:06.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  3. #3
    Join Date
    Aug 2008
    Posts
    58
    Quote Originally Posted by Teddy View Post
    *1:
    What you're talking about pretty much demands a separation between presentation and content. When you're talking about database entities, it will cause fewer headaches if you don't also involve the presentation objects in that conversation.

    *2:
    Again, you're talking about a fairly textbook n-tiered approach in which you have your database, a data access class, some business objects, and a way to look at/manipuate those business objects. With this approach, the standard way of doing things is to have a class that represents a single object, and then create a separate class (or use generics if they're available, List<of T>) to deal with collections of your single objects. Assuming the overhead of this approach is indeed justified by your business requirements, I would suggest sticking relatively close to the best patterns and practices model of having your "view" form consume a custom collection of your objects, and having your "edit" form work with a single custom business object.

    *3:
    Sorry, couldn't resist.

    *4:
    Access is a program like Crystal Reports, so I'm not sure where you're going with this one. What is it you don't like about Crystal specifically, other than obnoxious licensing? I would recommend looking at SSRS if it's available and you have SQL 2005+.
    Teddy, thanks for the informative reply. I necessarily don't mind going with the Custom Collection of single Custom Objects approach. I'll just have to figure out which methods will find a home in the collection class vs. the object class (for changing the sort order of a record, for example).

    No problem with Crystal Reports (I'm actually scheduled for a training on it in the near future), but I find the Access reporting function to be quite adequate for the needs of this application (not to mention easy to use).

    Thanks again and have a great holiday,

    J

  4. #4
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Quote Originally Posted by JManSF View Post
    Teddy, thanks for the informative reply. I necessarily don't mind going with the Custom Collection of single Custom Objects approach. I'll just have to figure out which methods will find a home in the collection class vs. the object class (for changing the sort order of a record, for example).
    sort order, as in ordinal position? That's a property on the object itself, so it should live there. Collection classes are designed to give you the common stuff like:
    .Add
    .Remove
    .Next
    .Item()
    .Sort
    .SomeOtherThingThatWouldBeUsefulToPerformAgainstAC ollectionInGeneral

    No problem with Crystal Reports (I'm actually scheduled for a training on it in the near future), but I find the Access reporting function to be quite adequate for the needs of this application (not to mention easy to use).
    From what it sounds like, the UI component isn't where the meat of your requirements are. You're talking about a robust application architecture that calls for a fair bit of flexibility and certainly requires the ability to work with business and data access components in an object oriented manner. Access is really, REALLY bad at that. On the other hand, .NET can handily address both requirements without breaking a sweat... but it takes more work, depending on how you look at things.

    That said, I'd encourage you to look at how much more work it would take to complete the reporting requirements in crystal/active reports/ssrs/what-have-you against how much more work it would take to complete the guts of the application in Access vs. a contemporary object-oriented language that is designed with your architecture in mind.

    I don't know your specific specs, so that could very well go either way...

    *Edit: If I get where you were going with that sort order thing, I think you would be talking about simply moving objects around in your collection and binding to them based on their ordinal position within the collection. That's the standard way databinding to collections works in .NET. If you have values 1, 2, 3 and 4 in a List<of Int> and bind to it, whatever bound itself to that list will display records in that order. If you subsequently moved "4" to the third position of the list and re-bound, the databound control would pick up on the new order and give you 1, 2, 4, 3.

    In short, the order of your objects is merely a function of their ordinal position within the list as opposed to being a property of your object itself. This another area where .NET will slaughter Access due to .NET's ability to bind data-aware controls to any kind of enumerable list you throw at it. Doesn't have to be a recordset, it can be a collection of business objects, no problem.
    Last edited by Teddy; 11-25-09 at 19:37.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  5. #5
    Join Date
    Aug 2008
    Posts
    58
    Quote Originally Posted by Teddy View Post
    sort order, as in ordinal position? That's a property on the object itself, so it should live there. Collection classes are designed to give you the common stuff like:
    .Add
    .Remove
    .Next
    .Item()
    .Sort
    .SomeOtherThingThatWouldBeUsefulToPerformAgainstAC ollectionInGeneral



    From what it sounds like, the UI component isn't where the meat of your requirements are. You're talking about a robust application architecture that calls for a fair bit of flexibility and certainly requires the ability to work with business and data access components in an object oriented manner. Access is really, REALLY bad at that. On the other hand, .NET can handily address both requirements without breaking a sweat... but it takes more work, depending on how you look at things.

    That said, I'd encourage you to look at how much more work it would take to complete the reporting requirements in crystal/active reports/ssrs/what-have-you against how much more work it would take to complete the guts of the application in Access vs. a contemporary object-oriented language that is designed with your architecture in mind.

    I don't know your specific specs, so that could very well go either way...

    *Edit: If I get where you were going with that sort order thing, I think you would be talking about simply moving objects around in your collection and binding to them based on their ordinal position within the collection. That's the standard way databinding to collections works in .NET. If you have values 1, 2, 3 and 4 in a List<of Int> and bind to it, whatever bound itself to that list will display records in that order. If you subsequently moved "4" to the third position of the list and re-bound, the databound control would pick up on the new order and give you 1, 2, 4, 3.

    In short, the order of your objects is merely a function of their ordinal position within the list as opposed to being a property of your object itself. This another area where .NET will slaughter Access due to .NET's ability to bind data-aware controls to any kind of enumerable list you throw at it. Doesn't have to be a recordset, it can be a collection of business objects, no problem.
    Timing constraints unfortunately preclude me from starting this project in .NET. Perhaps that will be phase 2.

    I believe the method you described for manipulating the ordinal position of objects in a collection would not persist after the user exits the application, right? When I mentioned "sort order" I was referring to the numerous general reference tables that populate combo and list boxes throughout the app. These tables basically all have three fields: an Id field, a Title field, and a Sort field. The sort field just lets the user decide how the lists are sorted. I need to store this because the search results will follow the same sort order. Modifying this sort order is simple enough (to move lower, set current record's sort to Sort + 1 and next record's sort to Sort - 1, etc.), unfortunately it requires access to more than one record in the table. Unless I'm missing something, that would have to be taken care of in the collection class, not the object class.

  6. #6
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    I would probably address it in the database itself. I'd rather send just the object that I care about persisting as opposed to making n round trips where n is the number of objects in my collection. Barring the likely hood of making a whole slew of ordinal position changes at the same time in which case I might go ahead and take care of that logic app or client side.

    Say you're taking an object in through a sproc. If you have @ORDINAL_POSITION as one of your sproc parameters, you can test @ORDINAL_POSITION against what's currently in the table for that item and decide whether it moved up or down. Then you can take care of reorganizing ordinal values for the group of records the incoming DAL object belongs to using a simple update statement (ie: SET ordinal_position = ordinal_position - 1 WHERE ordinal_position >= @ORIGINAL_POSITION AND ordinal_position <= @ORDINAL_POSITION) . You then have the option of refreshing your collection or not, depending on what you're doing at the time.

    Since you're not working with .NET, chances are you won't be passing in strongly typed collections of objects to the database itself, so you'll always be effectively dealing with one and only one update/insert at a time and shouldn't run in to any problems with trying to deal with multiple changes in ordinal positions at the same time. That simplifies things a good deal.



    **Also, time constraints may prohibit you from modeling this kind of architecture in Access.
    Last edited by Teddy; 11-25-09 at 20:12.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •