today i've started with the implementation.
i implemented today the ProjectPersistance class and it passed the tests that i made. i've tested it with the testdriven.net tool, which is a add-in for vs.net. when i run the same tests with nunit. they fail nearly all. i think nunit runs the tests in alphabetically order and not in the order the tests are written in the sourcefile. because for some test i need the datas from a previous test. should i fix that? and make the tests autonomous from the others?
for the compilation of the source files i added an interface ICompile in the data layer. i think thats a good solution, so we can add the compilation for other programming languages in later, later iterations simply. the class CSharpCompile implements this interface and is responsible for the compilation.
@reto:
- the Synchronizer class is the process, which starts the synchronization. the ProjectSynchronizer executes the sanchronization. i think, i should describe this in the design document.
- i don't understand what you mean with the renaming from Log to ChangeLog. for me the names are clear. can you make an example?
- your solution for the locking problem sounds good. thanks
- i'll correct the names in the sequence diagrams

3 Comments:
NUNIT:
Here a possible extension for NUNIT which supports sequencing.
http://www.codeproject.com/csharp/autp3.asp
If your current approach with testdriven.net works works fine I would just go with that.
ICompile: Good idea.
Log:
Log is a very generic name and can be easily misunderstood by error logs or so. To make it more clear I would name it ChangeLog instead.
Locking:
The only disadvantage I see with my approach is that it's not extendable to who has locked the file. In the future we might want to add that and tell a user that this page has been locked by "User123". For now, I think it's ok.
Think about conflict resolution again instead of logging. It does not make it more complicated but easier, because we don't have to implement the whole locking stuff. You just test if the documentation of that item has changed before you write it back. if it did, ask the user which version he likes. done. Sound much easier to me and much more userfriendly too. with locking we will run into issues for sure, specially if something fails at some point, then we have files that are still locked, etc. belive me, i've been there. it's not pretty :-)
Remy is right. The file locking seems to be a dead end street and doesn't make me feel convinced in a long run neither. Let's remove this file locking and prompt the user a message saying that the comment was changed in the meantime and whether to use his or the other persons version. This way we will have a clean and user friendly solution.
Post a Comment
<< Home