Writing A Database As Back-End For Application Developed By Others
-
I've written lots of small applications where I work, developing the databases in SQL Server, which is my forte, and the front ends in ASP.NET. When I've been doing it all myself it's been easy because, as the application developer, I know the databases and have no trouble writing ad-hoc queries in the application or, more often, calling Stored Procedures that I've written, knowing what parameters are required, and so on. But now I'm embarking on a much larger project, for which we'll be hiring developers to write the application. I'm just writing the database. My plan was to write well-documented Stored Procedures to perform every operation required on the database - inserting, updating, deleting, retrieving records, and so on, and then letting the developers just call these procedures from the application without them needing to know the database's structure, effectively creating an API. If I have time, I also intended to write web services as an intermediate level for them to use, so that they call these services rather than the Stored Procedures. I don't know how much benefit there is to doing this for the core .NET application, but since we intend to also create mobile apps down the line, the same services could be used for those as well. This morning I've been reading about CRUD and writing RESTful services and so on (not completely understanding it all), and now I'm starting to wonder if I'm missing something. I want to set up an API, so to speak, that will seem sensible, easy to work with and perhaps even familiar to our experienced developers after they are recruited, but since this is the first time I've worked in this way I'm not really sure what they'll be expecting. I want to work in line with best practice to deliver a successful project and an excellent product. Does my proposed plan fit this requirement, or should I be doing something else? EDIT: Maybe I'd get more useful replies if this was in the Web Development thread? Can a mod move it?
-
I've written lots of small applications where I work, developing the databases in SQL Server, which is my forte, and the front ends in ASP.NET. When I've been doing it all myself it's been easy because, as the application developer, I know the databases and have no trouble writing ad-hoc queries in the application or, more often, calling Stored Procedures that I've written, knowing what parameters are required, and so on. But now I'm embarking on a much larger project, for which we'll be hiring developers to write the application. I'm just writing the database. My plan was to write well-documented Stored Procedures to perform every operation required on the database - inserting, updating, deleting, retrieving records, and so on, and then letting the developers just call these procedures from the application without them needing to know the database's structure, effectively creating an API. If I have time, I also intended to write web services as an intermediate level for them to use, so that they call these services rather than the Stored Procedures. I don't know how much benefit there is to doing this for the core .NET application, but since we intend to also create mobile apps down the line, the same services could be used for those as well. This morning I've been reading about CRUD and writing RESTful services and so on (not completely understanding it all), and now I'm starting to wonder if I'm missing something. I want to set up an API, so to speak, that will seem sensible, easy to work with and perhaps even familiar to our experienced developers after they are recruited, but since this is the first time I've worked in this way I'm not really sure what they'll be expecting. I want to work in line with best practice to deliver a successful project and an excellent product. Does my proposed plan fit this requirement, or should I be doing something else? EDIT: Maybe I'd get more useful replies if this was in the Web Development thread? Can a mod move it?
Design and Architecture would probably be a better forum but the same people will look at it as here... If you are confident at designing the data structure and getting it right then I would suggest doing everything up to the WCF/Service layer. However as you sound like a particularly advanced power user I would probably look at getting a senior dev to work with you on the database and service and when that is in place get the UI devs on board to complete the application. Be prepared to change your design as dictated by the UI, forget the crap about agile you may hear, the best apps are built by people who recognise a design error early and fix it NOW.
Never underestimate the power of human stupidity RAH
-
I've written lots of small applications where I work, developing the databases in SQL Server, which is my forte, and the front ends in ASP.NET. When I've been doing it all myself it's been easy because, as the application developer, I know the databases and have no trouble writing ad-hoc queries in the application or, more often, calling Stored Procedures that I've written, knowing what parameters are required, and so on. But now I'm embarking on a much larger project, for which we'll be hiring developers to write the application. I'm just writing the database. My plan was to write well-documented Stored Procedures to perform every operation required on the database - inserting, updating, deleting, retrieving records, and so on, and then letting the developers just call these procedures from the application without them needing to know the database's structure, effectively creating an API. If I have time, I also intended to write web services as an intermediate level for them to use, so that they call these services rather than the Stored Procedures. I don't know how much benefit there is to doing this for the core .NET application, but since we intend to also create mobile apps down the line, the same services could be used for those as well. This morning I've been reading about CRUD and writing RESTful services and so on (not completely understanding it all), and now I'm starting to wonder if I'm missing something. I want to set up an API, so to speak, that will seem sensible, easy to work with and perhaps even familiar to our experienced developers after they are recruited, but since this is the first time I've worked in this way I'm not really sure what they'll be expecting. I want to work in line with best practice to deliver a successful project and an excellent product. Does my proposed plan fit this requirement, or should I be doing something else? EDIT: Maybe I'd get more useful replies if this was in the Web Development thread? Can a mod move it?
phil2415 wrote:
This morning I've been reading about CRUD and writing RESTful services and so on (not completely understanding it all)
Rest applies to the application server not to the database. The application server deals with a data model where objects in that often but not always map to tables in the database. It that 'not always' part that means that the application server should have its own data model and then map that to the database. The stored procedures provide the access layer to the database. Far as I am concerned they (stored procs) server the same purpose as any other application layer so I am in favor of them. Additionally I consider the permissions possible with them a win.
phil2415 wrote:
I'm not really sure what they'll be expecting.
First thing of course is that someone, somewhere needs to come up with a data model. Doesn't need to be formal but a team (more than one person) can't work without a division of labor and so they need to target a data model and so do you. You should of course be prepared to participate in that process. You might even be the sole person given that you have experience both in database and application development. Your role other than that would be in insuring that the data model is not going to impose problems such as performance. Then normal DDL development with any additional database tests (archive, back up, etc) that would normally be identified in any production system. Depending on the team/project you might also be in charge of writing the application side abstraction layer - the thing that interfaces with the stored proc. Of course one potential problem with all of the above is that one of the incoming people already has an idea how the database should be done and it doesn't jive with your view.
-
I've written lots of small applications where I work, developing the databases in SQL Server, which is my forte, and the front ends in ASP.NET. When I've been doing it all myself it's been easy because, as the application developer, I know the databases and have no trouble writing ad-hoc queries in the application or, more often, calling Stored Procedures that I've written, knowing what parameters are required, and so on. But now I'm embarking on a much larger project, for which we'll be hiring developers to write the application. I'm just writing the database. My plan was to write well-documented Stored Procedures to perform every operation required on the database - inserting, updating, deleting, retrieving records, and so on, and then letting the developers just call these procedures from the application without them needing to know the database's structure, effectively creating an API. If I have time, I also intended to write web services as an intermediate level for them to use, so that they call these services rather than the Stored Procedures. I don't know how much benefit there is to doing this for the core .NET application, but since we intend to also create mobile apps down the line, the same services could be used for those as well. This morning I've been reading about CRUD and writing RESTful services and so on (not completely understanding it all), and now I'm starting to wonder if I'm missing something. I want to set up an API, so to speak, that will seem sensible, easy to work with and perhaps even familiar to our experienced developers after they are recruited, but since this is the first time I've worked in this way I'm not really sure what they'll be expecting. I want to work in line with best practice to deliver a successful project and an excellent product. Does my proposed plan fit this requirement, or should I be doing something else? EDIT: Maybe I'd get more useful replies if this was in the Web Development thread? Can a mod move it?
I agree with developing up through the Web Service part as an API so the application developers don't need to even know there's a database involved. <YouProbablyAlreadyKnowThis> Be sure that at the API level the methods are written as high-level application operations, rather than as specific database operations. E.g. if a transaction requires two INSERTs and an UPDATE, those details should be hidden in one method rather than requiring the application developers to know that they need to call three methods and in what order. </YouProbablyAlreadyKnowThis>
-
I agree with developing up through the Web Service part as an API so the application developers don't need to even know there's a database involved. <YouProbablyAlreadyKnowThis> Be sure that at the API level the methods are written as high-level application operations, rather than as specific database operations. E.g. if a transaction requires two INSERTs and an UPDATE, those details should be hidden in one method rather than requiring the application developers to know that they need to call three methods and in what order. </YouProbablyAlreadyKnowThis>
-
phil2415 wrote:
This morning I've been reading about CRUD and writing RESTful services and so on (not completely understanding it all)
Rest applies to the application server not to the database. The application server deals with a data model where objects in that often but not always map to tables in the database. It that 'not always' part that means that the application server should have its own data model and then map that to the database. The stored procedures provide the access layer to the database. Far as I am concerned they (stored procs) server the same purpose as any other application layer so I am in favor of them. Additionally I consider the permissions possible with them a win.
phil2415 wrote:
I'm not really sure what they'll be expecting.
First thing of course is that someone, somewhere needs to come up with a data model. Doesn't need to be formal but a team (more than one person) can't work without a division of labor and so they need to target a data model and so do you. You should of course be prepared to participate in that process. You might even be the sole person given that you have experience both in database and application development. Your role other than that would be in insuring that the data model is not going to impose problems such as performance. Then normal DDL development with any additional database tests (archive, back up, etc) that would normally be identified in any production system. Depending on the team/project you might also be in charge of writing the application side abstraction layer - the thing that interfaces with the stored proc. Of course one potential problem with all of the above is that one of the incoming people already has an idea how the database should be done and it doesn't jive with your view.
Thanks for the advice. I'm already devising the data model for the database. My idea is that before the developers even arrive, the bulk of the database will be written and SPs in place for handling fundamental operations. I've no doubt that changes will need to be made once the development team starts, but hopefully the basic foundations should be fairly sound.
-
Design and Architecture would probably be a better forum but the same people will look at it as here... If you are confident at designing the data structure and getting it right then I would suggest doing everything up to the WCF/Service layer. However as you sound like a particularly advanced power user I would probably look at getting a senior dev to work with you on the database and service and when that is in place get the UI devs on board to complete the application. Be prepared to change your design as dictated by the UI, forget the crap about agile you may hear, the best apps are built by people who recognise a design error early and fix it NOW.
Never underestimate the power of human stupidity RAH