Questions

Rapid Application Development - HELP!

Tags:
+
0 Votes
Locked

Rapid Application Development - HELP!

cg7780_123
I'll try to get to the point quickly here. I appreciate any and all information I can get!

I manager a small team developing applications for internal business processes. The technology we are using is .adp (.ade for the executable). If you are not familiar this is forms/reports built in MS Access (in this case 2007) with all the data residing on SQL server. So basically a client-server architecture. We utilize some server-side technologies as well such as views, stored procedures etc. We've developed an extremely powerful and valuable application and are looking for an opportunity to start utilizing more "enterprise" grade technologies (i.e. Java, VB.NET, C#.NET etc.)

So a couple questions for the TechRepublic universe:

1. Do you know of any explicit limitations of .adp architecuture (explained above)? Or have any opinions as to what risks we run by continuing to grow our user base by sticking with this architecture? (Currently 35-40 concurrent users looking to expand to up to 80-100)

2. My main problem is that I have two developers who's primary expertise is developing in this architecure, so I'm looking for opinions on a good Rapid Application Development architecture that would "feel" similar to the type of development done in MS Access front-end and/or a Visual Studio feel. Basically I'm trying to find a language that would be much more scaleable without "starting from scratch" from a learning curve perspective.

Thank you all very much!!
  • +
    0 Votes
    cg7780_123

    Just an additional note in case any of you were wondering; We developed our solutions using the .adp architecture due primarily to our ability to quickly make changes, bug fixes, add-ons etc. We are embedded in the business and need to make changes very quickly for mission-critical processes that we support through our applications. Thanks again!!

    +
    0 Votes
    Tony Hopkinson

    Me I'd give your guys a bit of time to potter. Download visual studio express pick a language bash togther some forms that use your current archictecture. Then it's a course, or may be a consultant to help you and them set up. VB.net if they are doing VBA might ease the burden, be wary of being lured into the it's just the same, it isn't.

    Duplicate a bit of your current app, view into a grid on a form open, close, login etc.

    It might feel at first like it's from scratch but of they are half way decent they will see their skills map.


    Achitecturally I can't see you having a problem, it' sql server that doing the work, it scales well past where you are talking about.

    PS if you don't have it some form of source control is a must.

    +
    0 Votes

    OOD

    cg7780_123

    Sounds like VB.NET will probably be the most comfortable but I agree it probably won't be the same. Syntax similarities and how forms look will be the same which may be the extent of it....however we are taking on a huge effort of converting alot of the procedureal code into OOD using VBA Class modules. We have alot of oppportunity for code reuse, currently our app is 33k lines of code, I want to reduce this as I know there is opportunity to do so. OOD in VBA is powerful although some of the most powerful features of OOD don't seem available (i.e. inheritance, polymorphism). The way I see it is this; if we get as much of our code into class modules with OOD in VBA then the translation into a full OOD language may be quicker. You'll know that you have to build a class that handles user mainteinance (i.e. add user, change pw, admin reset, unlock etc.) just because it's built in VBA doesn't mean you can just rebuild that class in Java or VB.NET. In other words the idea is our framework and design will be there and what language it's written in becomes just a matter of syntax translation.

    +
    0 Votes
    Tony Hopkinson

    While there's a fair learning curve in the language and framework, the real killer is the design paradigm shift.

    The more you think OO in what you have now the easier the shift.

    PS don't go loony with inheritance, it's a real future killer, look at aggregation and interfaces.

    +
    0 Votes
    cg7780_123

    I agree the more we think in objects the easier the transition will be. I personally like to get my hands dirty while managing my small team so what I've found is that thinking in "classes" is the first step (or is it the same as thinking in objects?).

    Basically I'm looking at our procedureal "hot mess" :) and looking for redundant functionality, then thinking about consolidating similar functionality into a cohesive class module.

    For example we have some code on form A that packages a report into a .pdf and emails it, then we have code on form B that downloads a recordset into excel for end users to do further analysis, then a whole multitude of little "filter forms" for running any other reports. I'm looking at this as an opportunity to consolidate all of this code into a class called: "cls_Reporting". This class will have functions that package reports into a .pdf and email, then another that filters, another that downloads into excel etc etc. Is this the right approach, in your opinion on this limited example are we "thinking in objects" (i.e. the "reporting" object).

    Thanks Tony, your responses have been outstanding!!

    +
    0 Votes
    Tony Hopkinson

    given what you have avilable in VBA.
    Evert function / property you wrap up in class now is one you have a head start on.

    In .net Initally be thinking interfaces.

    An interface is a contract

    Email for intance would take a PDF as an attachment, and a bit of waffle for the email. Recipient, subject and body.

    Very little to do with all the detailed gubbins that created the report that was transformed to a pdf.

    So you might in .net say your class BigCustomerReport implements IEMail.

    Then have a UI which vased on selecting a recipient shows all the 'emailable' things you could send...

    You/they might want to email the excel spreadsheet, or a csv...

    It's not a decision you have to make now in VBA, but don't think common code, think common behaviours.

    HtHs

    There are even better things you can do in .net, look up Custom Attributes, Reflection and Extensions.

    Don't go mad though, even though it's a great deal of fun.

    +
    0 Votes
    cg7780_1234

    You're the man Tony, I'd love to start a discussion on how VBA programmers can start to "train themselves" to "think in objects" to prepare for expansion into OO programming in .net, Java, C# etc. etc. I'll probably post something here in the next few days. I think you input would be extremely valuable to the TechRepublic community.

    Thanks a ton for all your quick posts and input, it's been alot of help!!

  • +
    0 Votes
    cg7780_123

    Just an additional note in case any of you were wondering; We developed our solutions using the .adp architecture due primarily to our ability to quickly make changes, bug fixes, add-ons etc. We are embedded in the business and need to make changes very quickly for mission-critical processes that we support through our applications. Thanks again!!

    +
    0 Votes
    Tony Hopkinson

    Me I'd give your guys a bit of time to potter. Download visual studio express pick a language bash togther some forms that use your current archictecture. Then it's a course, or may be a consultant to help you and them set up. VB.net if they are doing VBA might ease the burden, be wary of being lured into the it's just the same, it isn't.

    Duplicate a bit of your current app, view into a grid on a form open, close, login etc.

    It might feel at first like it's from scratch but of they are half way decent they will see their skills map.


    Achitecturally I can't see you having a problem, it' sql server that doing the work, it scales well past where you are talking about.

    PS if you don't have it some form of source control is a must.

    +
    0 Votes

    OOD

    cg7780_123

    Sounds like VB.NET will probably be the most comfortable but I agree it probably won't be the same. Syntax similarities and how forms look will be the same which may be the extent of it....however we are taking on a huge effort of converting alot of the procedureal code into OOD using VBA Class modules. We have alot of oppportunity for code reuse, currently our app is 33k lines of code, I want to reduce this as I know there is opportunity to do so. OOD in VBA is powerful although some of the most powerful features of OOD don't seem available (i.e. inheritance, polymorphism). The way I see it is this; if we get as much of our code into class modules with OOD in VBA then the translation into a full OOD language may be quicker. You'll know that you have to build a class that handles user mainteinance (i.e. add user, change pw, admin reset, unlock etc.) just because it's built in VBA doesn't mean you can just rebuild that class in Java or VB.NET. In other words the idea is our framework and design will be there and what language it's written in becomes just a matter of syntax translation.

    +
    0 Votes
    Tony Hopkinson

    While there's a fair learning curve in the language and framework, the real killer is the design paradigm shift.

    The more you think OO in what you have now the easier the shift.

    PS don't go loony with inheritance, it's a real future killer, look at aggregation and interfaces.

    +
    0 Votes
    cg7780_123

    I agree the more we think in objects the easier the transition will be. I personally like to get my hands dirty while managing my small team so what I've found is that thinking in "classes" is the first step (or is it the same as thinking in objects?).

    Basically I'm looking at our procedureal "hot mess" :) and looking for redundant functionality, then thinking about consolidating similar functionality into a cohesive class module.

    For example we have some code on form A that packages a report into a .pdf and emails it, then we have code on form B that downloads a recordset into excel for end users to do further analysis, then a whole multitude of little "filter forms" for running any other reports. I'm looking at this as an opportunity to consolidate all of this code into a class called: "cls_Reporting". This class will have functions that package reports into a .pdf and email, then another that filters, another that downloads into excel etc etc. Is this the right approach, in your opinion on this limited example are we "thinking in objects" (i.e. the "reporting" object).

    Thanks Tony, your responses have been outstanding!!

    +
    0 Votes
    Tony Hopkinson

    given what you have avilable in VBA.
    Evert function / property you wrap up in class now is one you have a head start on.

    In .net Initally be thinking interfaces.

    An interface is a contract

    Email for intance would take a PDF as an attachment, and a bit of waffle for the email. Recipient, subject and body.

    Very little to do with all the detailed gubbins that created the report that was transformed to a pdf.

    So you might in .net say your class BigCustomerReport implements IEMail.

    Then have a UI which vased on selecting a recipient shows all the 'emailable' things you could send...

    You/they might want to email the excel spreadsheet, or a csv...

    It's not a decision you have to make now in VBA, but don't think common code, think common behaviours.

    HtHs

    There are even better things you can do in .net, look up Custom Attributes, Reflection and Extensions.

    Don't go mad though, even though it's a great deal of fun.

    +
    0 Votes
    cg7780_1234

    You're the man Tony, I'd love to start a discussion on how VBA programmers can start to "train themselves" to "think in objects" to prepare for expansion into OO programming in .net, Java, C# etc. etc. I'll probably post something here in the next few days. I think you input would be extremely valuable to the TechRepublic community.

    Thanks a ton for all your quick posts and input, it's been alot of help!!