Java Design – How to Handle Nested Collections More Elegantly

You could use a xor linked list variant (using indexes into an array for the pointer).

Then reversing is easy:

reverse(int city1prev, int city1index, int city2prev, int city2index)
{

    int city1next = array[city1index].ptr^city1prev;
    int city2next = array[city2index].ptr^city2prev;

    city1.ptr = city2next^city1next;
    city2.ptr = city2prev^city1prev;

    array[city1prev].ptr^= city1index^city2index;
    array[city2next].ptr^= city1index^city2index;

}

The downside is (as with all linked list implementations) that indexing into it is O(n).

This will reverse the sub array due to how the xor link works: city2 will be where city1 used to be and city2prev will be after it and so on. So the new sequence becomes: city1prev, city2, city2prev,..., city1next, city1, city2next.

Key point is that there is no difference between traversing a xor linked list forward or backward (you keep a index to the current and the previous items and you get the next by doing array[current].ptr^previous).

Your website should have a separate set of ViewModels which wrap the domain models and any other data/logic required by the page.

Because these view models belong to the website rather than the domain its ok to stick on any validation or extra logic which is only required by the website/View for the particular process you are implementing.

I think the best example is say you have some process 'Sign Up' the domain model for which includes a ton of data about the person signing up. Your design teams comes up with two designs.

• Design 1: A large single page form with all the fields on

• Design 2: A 'Wizard' approach with multiple separate forms

Although both designs use the same underling logic for signing up. each will have very different view models.

update ---

Entity Framework data annotations allow EF to correctly map your object to a database table. There are some conventions which will allow you to get away with not using some of them of your properties are named as expected.

However, you are correct in that if you want to separate your domain objects from the persistence logic you will need to implement an Entity Object which mirrors the properties on your domain object and to which you can add the data annotations.

You can wrap all this in a repository object which can get the Entity objects back from the DB, convert them to your Domain objects and return them to the calling code. However if you do all these things you will find that you have lost the time saving benefits of EF and might as well have just used SqlClient

In the ideal world you solution structure might look like this:

DomainModels - class lib
    User.cs

EntityModels - class lib
    UserEntity.cs - with data annotations

RepositoryEF - class lib ref domain and entity
    UserRepository.cs - eg. public User GetUser(string id)

Website - ref the other three
    UserController.cs - calls repository to get a domain object
    UserViewModel.cs - populated from domain object by controller
    UserView.cshtml - uses viewmodel as its model and displays data to user