Simple App Strategy
-
I'm musing over my development strategy for a very simple app for a client. They basically need a single form for edit and display of records from a single table. They also need a search on fields from that form. Now I've never done this small an app for a client, so I have always gone the whole hog with data access layer etc., custom business objects etc. but I think for this app I would like to go with the RAD features VS provides out of the box (data binding etc.). I realise that later on we may need to expand the capabilities of the app, but I think even then the simplicity of the general business requirements will still allow this. I'm just curious whether there are any serious caveats in taking this approach?
-
I'm musing over my development strategy for a very simple app for a client. They basically need a single form for edit and display of records from a single table. They also need a search on fields from that form. Now I've never done this small an app for a client, so I have always gone the whole hog with data access layer etc., custom business objects etc. but I think for this app I would like to go with the RAD features VS provides out of the box (data binding etc.). I realise that later on we may need to expand the capabilities of the app, but I think even then the simplicity of the general business requirements will still allow this. I'm just curious whether there are any serious caveats in taking this approach?
I have two comments. First if the Company has an intranet and a web server I would think seriously of making a web app. Makes it easy for anyone in the company to use the app. You might need to add some login stuff if they only want certain users to be able to access or edit the data. With a web app you don't have any deployment or update issues. Ok second, if you still need to build the windows app if you have a data access layer that is a component or project you can easily add to the windows project solution I would just add it. I don't think there is any issue leaving out the business layer in this case since the app is just a simple editor. If you data layer isn't easy to port to other apps, then you probably have a different problem. In general it is nice to be consistant with data access across projects. Ben
-
I'm musing over my development strategy for a very simple app for a client. They basically need a single form for edit and display of records from a single table. They also need a search on fields from that form. Now I've never done this small an app for a client, so I have always gone the whole hog with data access layer etc., custom business objects etc. but I think for this app I would like to go with the RAD features VS provides out of the box (data binding etc.). I realise that later on we may need to expand the capabilities of the app, but I think even then the simplicity of the general business requirements will still allow this. I'm just curious whether there are any serious caveats in taking this approach?
I reckon I'd start with the datasource, create the dataset & a mini data access layer, then work on the UI. Simple and deliverable in a few hours (sans testing/documentation). I'd choose this approach as it's an app for a client & this is a familiar way of doing things for me hence less likely to screw up & deliver buggy software. I know you'd like to use the RAD features on this but perhaps the "learning curve" here is better suited to a personal project for now? My opinion only.
-
I reckon I'd start with the datasource, create the dataset & a mini data access layer, then work on the UI. Simple and deliverable in a few hours (sans testing/documentation). I'd choose this approach as it's an app for a client & this is a familiar way of doing things for me hence less likely to screw up & deliver buggy software. I know you'd like to use the RAD features on this but perhaps the "learning curve" here is better suited to a personal project for now? My opinion only.
Could you give me some hint as to how you would do the DAL and dataset? I would normally do entities and a data access service for reading and writing entities to the database. Maybe you're right about the learning curve, I could always repeat the project with the RAD features as an RnD project once its delivered. I will have lots of iteration on this, so if I come up to speed on the RAD project I could swap it out.
-
Could you give me some hint as to how you would do the DAL and dataset? I would normally do entities and a data access service for reading and writing entities to the database. Maybe you're right about the learning curve, I could always repeat the project with the RAD features as an RnD project once its delivered. I will have lots of iteration on this, so if I come up to speed on the RAD project I could swap it out.
It depends on the context to a fairly large degree IMO. As I understand it, it's a one table database/source with a single form. Depending on how much data needs to be worked with, how it needs to be interpreted & whether it needs to be shared across a LAN, etc. I'd decided on whether to use a database or an XML file. These and other decisions can really only be made in the context of the project's scope. Here are my assumptions - it's a single client appliaction that needs to use a single table database, must be searchable, filtered, sorted, etc. My approach would most likely be 1. Create a test plan. Using a "test first" approach works really well for RAD. Personally I find that it tends to cut out the "extra features" bull that we as developers all too often add on & allows you to concentrate on delivering core functionality & what the client REALLY wants. Doesn't have to be a massive testing framework, just an accurate guide that you will stick to. 2. Create database & populate with sample data. 3. Create a dataset outside of the form (not as part of the single form) that'll be used for accessing/manipulating data. 4. Create a class (or set of classes depending on requirements) that will contain the core functionality of the app. Remember to still use your test plan. 5. Hook the UI up to the aforementioned class(es) using as simplistic an approach as possible. Create new controls only if absolutely necessary as this will extend your time to delivery. 6. Pass it on to the client for evaluation, & the usual story thereafter. That help any?
-
It depends on the context to a fairly large degree IMO. As I understand it, it's a one table database/source with a single form. Depending on how much data needs to be worked with, how it needs to be interpreted & whether it needs to be shared across a LAN, etc. I'd decided on whether to use a database or an XML file. These and other decisions can really only be made in the context of the project's scope. Here are my assumptions - it's a single client appliaction that needs to use a single table database, must be searchable, filtered, sorted, etc. My approach would most likely be 1. Create a test plan. Using a "test first" approach works really well for RAD. Personally I find that it tends to cut out the "extra features" bull that we as developers all too often add on & allows you to concentrate on delivering core functionality & what the client REALLY wants. Doesn't have to be a massive testing framework, just an accurate guide that you will stick to. 2. Create database & populate with sample data. 3. Create a dataset outside of the form (not as part of the single form) that'll be used for accessing/manipulating data. 4. Create a class (or set of classes depending on requirements) that will contain the core functionality of the app. Remember to still use your test plan. 5. Hook the UI up to the aforementioned class(es) using as simplistic an approach as possible. Create new controls only if absolutely necessary as this will extend your time to delivery. 6. Pass it on to the client for evaluation, & the usual story thereafter. That help any?
Yes and no. Your reply confirms my initial strategy (and I'm a big TDD fan), but I was considering doing a 'no-code' type implementation, using VS wizards etc. Forgoing that and using a properly coded DAL seems the generally preferred method, as well as being my preferred method, so I will be going with that. And it allows me to test first!
-
Yes and no. Your reply confirms my initial strategy (and I'm a big TDD fan), but I was considering doing a 'no-code' type implementation, using VS wizards etc. Forgoing that and using a properly coded DAL seems the generally preferred method, as well as being my preferred method, so I will be going with that. And it allows me to test first!
My mistake in interpretation, sorry. I've done some of the "no code" approach in ASP.NET & found that to be pretty easy and efficient but it feels clumsy when applied to winforms apps (at least to me it does), which is why I tend to avoid it and go the "old faithful" route. :)
-
My mistake in interpretation, sorry. I've done some of the "no code" approach in ASP.NET & found that to be pretty easy and efficient but it feels clumsy when applied to winforms apps (at least to me it does), which is why I tend to avoid it and go the "old faithful" route. :)
I've also found it clumsy, but I suspect it's from lack of familiarity. Anyway, I said I'd deliver a 'draft' by Friday, and didn't know Friday was a holiday, so it's a quick sprint with what's familiar later today.
-
I've also found it clumsy, but I suspect it's from lack of familiarity. Anyway, I said I'd deliver a 'draft' by Friday, and didn't know Friday was a holiday, so it's a quick sprint with what's familiar later today.
Good luck.