Where to start with the development of first database driven Web App (long question)?_问答_开发者

I've decided to develop a database driven web app, but I'm not sure where to start. The end goal of the project is three-fold:

to learn new technologies and practices,
deliver an unsolicited demo to management that would show how information that the company stores as office documents spread across a cumbersome network folder structure can be consolidated and made easier to access and 开发者_如何学JAVAmaintain and
show my co-workers how Test Driven Development and prototyping via class diagrams can be very useful and reduces future maintenance headaches.

I think this ends up being a basic CMS to which I have generated a set of features, see below.

Create a database to store the site structure (organized as a tree with a 'project group'->project structure).
Pull the site structure from the database and display as a tree using basic front end technologies.
Add administrator privileges/tools for modifying the site structure.
Auto create required sub pages* when an admin adds a new project.
4.1 There will be several sub pages under each project and the content for each sub page is different.
add user privileges for assigning read and write privileges to sub pages.

What I would like to do is use Test Driven Development and class diagramming as part of my process for developing this project. My problem; I'm not sure where to start. I have read on Unit Testing and UML, but never used them in practice. Also, having never worked with databases before, how to I incorporate these items into the models and test units?

Thank you all in advance for your expertise.

I have the feeling that you are trying to grab too much at once. It is fine to experiment with databases, TDD and UML diagrams; that in itself would IMHO be enough for a single project. This first experimental project will teach you a lot, based on which you will be able to do a much better job on the next project. But I would not expect this first try to bring results which can convince other developers to pick up TDD, and/or management to change its way of thinking. You need to understand and experience things at first yourself, before you can reasonably explain them to others.

For advice on unit testing DB apps, see these threads for starters:

What’s the best strategy for unit-testing database-driven applications?
Unit-Testing Databases
Unit tests framework for databases
Testing approach - DB, Junit

I am not sure what you mean by "prototyping via class diagrams". Class diagrams are fine for discussing / communicating your design to other developers, and should certainly be in the toolkit of every good developer. A whiteboard session with someone, sketching and erasing design elements on the fly is a great way to clarify the design and the forces influencing it. However, IMHO this is "prototyping" only in a very broad sense. A real prototype to me is code - that is the only way to verify whether or not your design really works in practice.

I'm not sure where to start.

We always start with the data model.

having never worked with databases before, how to I incorporate these items into the models and test units?

Ah, well, there's the problem.

You have to start with the data, because everything starts with the data.

Write use cases. Your 5 technical requirements aren't really very good use cases because there's no Actor who interacts with a system. You need to write down the things an actor does -- what the actor interacts with.
Identify the objects that the actor interacts with. When in doubt, write down all the nouns in your use cases.
Draw a picture of the classes that will implement those objects.
Walk through your use cases to be sure that all the things an Actor needs to do are based on attributes of your class definitions. All the data an actor needs has to be in these classes, which will become tables in your database.

Now, you have to start doing more technical work. You need a web framework with an ORM layer. You're using PHP, so you'll have to find a good framework for this. Cake or Doctrine or something.

Define one class in your ORM layer. You don't have to be complete or precise, you just need something that you can test with.
Write unit tests for this class to be sure that it has the right data elements. This will be relatively simple at first, since your individual data classes will start out simple.

Once the basic set of classes are defined, you'll need to look at relationships among classes. This is where the real work starts.

Look at a relationship in your picture. Any line. Pick one randomly.
Write unit tests to be sure that you can "navigate" across that line. From one object, fetch the related objects at the other end of the line. This shouldn't be very complex, just a few lines of code.
Create a "fixture" -- test data you can load into a database -- to represent the objects and their relationships.
Run the test. If it breaks, update your ORM definitions to support the navigation properly.

When you've finished doing all the various relationships, you will have built a reasonable complete data model in a Test-Driven manner.

Now you can build your PHP presentation for the model objects.

First the backbone of any web application is the database. I would suggest starting simple, doing up the database design and then writing model and view classes to render them. Second, you should design your DB with your goals in mind (sub-pages, tree structure) but don't be afraid to make mistakes. We could drill you on normalization or benefits of using a object relational model but if you personally don't see the need for those, it'll be hard to internalize the concepts.

TDD can be employed from day one, as you test the model and view classes of the DB. UML I am not sure it would be helpful - if possible just stick to sequence, class and collaboration diagrams.

A concrete answer for using DB in unit test - insert dummy rows during setup, and remove them during the teardown stages. You may want to write a PHP script to "clean up" a DB after testing.

Hope this helps!

What I would like to do is use Test Driven Development and class diagramming as part of my process for developing this project.

Those are 2 different approaches to design - you need to pick one. TDD drives the design based on behaviors and tests. UML tends to be used in BDUF (Big Design Up Front) - though it can be used just to informally communicate between devs without being a part of the "design". Bottom line, though - is that you need to decide how you want to design your software. For me, I'm usually more comfortable with a TDD approach - but for a well known domain, I may do a BDUF session instead (though I don't use UML).

My problem; I'm not sure where to start. I have read on Unit Testing and UML, but never used them in practice.

Assuming you're talking [T|B]DD, and not "unit testing" - you start with tests that prove the behaviors you need for your application. If you go the [T|B]DD route, I'd probably skip the UML entirely. Otherwise, just run a UML generator when you're done and it'll make you some pretty pictures. ;)

[TestFixture]
public class WhenAddingNewProject {
    [Test]
    public void SubPagesAreCreated() {
       var p = Project.Create("MyProjectGroup\\MyTestProject");

       Assert.IsGreaterThan(p.SubPages.Count, 0);
    }

    [Test]
    public void FirstSubPageIsWikiPage() {
       var p = CreateProject();
       var subPage = p.SubPages[0];

       Assert.AreEqual(subPage.Title == "MyTestProject Wiki");
       Assert.IsTypeOf<WikiSubPage>(subPage);
    }

    [Test(ExpectedException := typeof(SecurityException))]
    public void DefaultsToAdministratorPrivileges() {
       var p = CreateProject();

       var u = User.Login("testuser", "testpassword"); 
       Assert.IsNotNull(u);
       Assert.AreEqual(UserRole.User, u.Role);

       p.Delete();
       Assert.Fail();
    }

    private Project CreateProject() {
       return Project.Create("MyProjectGroup\\MyTestProject");
    }
}

Also, having never worked with databases before, how to I incorporate these items into the models and test units?

You don't. By definition, if you're hitting the database - you're running an integration test, not a unit test. For unit tests, you want to abstract the database out and ignore/mock/replace it. By getting your logic out of the database, you can test it separately - then you only need to test your loading/saving of data (you are using an ORM, right?).

My suggestion would be to start with ASP.NET MVC. There is a very good sample on building a simple web site with a database.

Look for more details here : The Nerd Dinner (Free download)

http://aspnetmvcbook.s3.amazonaws.com/aspnetmvc-nerdinner_v1.pdf

Why not to start with a class diagram ? You model your application then create the java code with JPA annotation coming directly from the model (e.g. stereotypes are also annotations) and finally you use a mapper such Hibernate / EJB 3 to create your database.