I have to agree with Wes on this one, extremely heavy (and often unnecessary) abstraction just makes things far too difficult to understand and deters developers from even considering using it because it's just too daunting.  Refactor and improve as needed - you can't anticipate everything everyone who ever uses your code will need, no matter how hard you try.  Such is the nature of software.

Pete, the viewer uses NHibernate for it's database and has an abstraction layer as well.  The fact that the DB code is in the same assembly as the DAL ... well, arguably that could be improved.  I agree that the interfaces could be more robust, but they serve their purpose for now.  The ImageServer and Ris also do this (far better than the viewer does, too) to make using other databases *very* possible.  You should have a look at the stuff in Enterprise - it's probably what you're looking for.

There are definitely shortcomings in the current viewer code, places where things are breaking down and don't quite meet our needs anymore.  All things we are aware of and intend to tackle at some point in the future.  For example, I fully intend to refactor things around how the viewer accesses data, making it more service-oriented.  Also, we are starting to find the current WCF services don't quite do everything that is needed, and they could use a bit of TLC.

Lastly, CC is definitely not tied to WinForms.  However, no matter how hard we try to make the model completely independent of little nuances in the view, it'll never fully succeed.  Undoubtedly, there will be things in the model that have to change when a new view is swapped in, but I imagine it would probably be minimal.

Stewart

I too am happy to see that a healthy debate seems to be surfacing here.  I just wanted to add a little bit of historical context to the architectural discussion.  The basis for the current design is the "Presentation Model" pattern:

http://martinfowler.com/eaaDev/PresentationModel.html

http://weblogs.macromedia.com/paulw..._pa_3.html

http://msdn.microsoft.com/en-us/library/cc707885.aspx

We opted for this pattern because it seemed to fit well with the data-binding capabilities offered by WinForms.  In CC terminology, the ApplicationComponent is the Presentation Model, and the view observes the presentation model through data-bindings.  We also had in mind the idea that if you wanted to create a different GUI using a different windowing toolkit, such as WPF or GTK, you would explicitly re-write all of the view plugins, but would not have to modify the ApplicationComponents.

We deliberately opted against using any kind of windowing abstraction layer between the application component and the view, because it was felt that a) the initial cost of writing this abstraction layer was too high, and more importantly, b) it would lead to a lowest common denominator scenario when the capabilities of one window toolkit could not match the capabilities of another.

In short, it was recognized early on that having to re-write the view layer for every windowing tooklit would be costly, but we still thought it was the best option, all things considered.  This is why the *.View.WinForms plugins are tightly coupled to Windows Forms.

It is great to get some perspective about the early design decisions. I completely undertand. Take  it from someone who supported COM objects for 10 years. I just wanted to share with you that there are these software migration bubbles where the longer you wait, the bigger the bubble gets and it always seems like it is better to put it off since resources are limited. I did that for many years even with a hefty design team because it seems that the amount of work fills up the available people and there is no time to look at new things. Since you have taken all this time to create such a flexible platform, I was being a little forceful in asking you to include in your development process a continuous migration strategy and dedicate some percentage, even a low percentage, of time to think about it and offer some perspective to all the developers of CC.

I won't mention this again and I await a VS2008 release :)

Ken

Hi,

I have a new install of VS2008 and would like to build CC.  Since you mentioned using the 1.0 framework, I pulled the ImageViewer1.0 tag from SVN.  I loaded the solution into VS2008, converted it to 2008 form, and tried building.  I got four errors (below).

The first error refers to CC.Dicom.OffisWrapper which is nowhere to be found in my solution.  Any ideas where I can find it?

Thanks,

-Steve

Error    1    The type 'ClearCanvas.Dicom.OffisWrapper.DcmDataset' is defined in an assembly that is not referenced. You must add a reference to assembly 'ClearCanvas.Dicom.OffisWrapper, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.    C:\src\ImageViewer1.0\ImageViewer\StudyFinders\Remote\RemoteStudyFinder.cs    140    7    ClearCanvas.ImageViewer.StudyFinders.Remote

Error    2    Unable to copy file "C:\src\ImageViewer1.0\ImageViewer\\..\ImageViewer\StudyFinders\Remote\bin\Debug\ClearCanvas.ImageViewer.StudyFinders.Remote.dll" to "C:\src\ImageViewer1.0\Desktop\Executable\\\bin\Debug\\plugins\ClearCanvas.ImageViewer.StudyFinders.Remote.dll". Could not find file 'C:\src\ImageViewer1.0\ImageViewer\\..\ImageViewer\StudyFinders\Remote\bin\Debug\ClearCanvas.ImageViewer.StudyFinders.Remote.dll'.    C:\src\ImageViewer1.0\ImageViewer\ImageViewer_dist.proj    155    5    ClearCanvas.Desktop.Executable

Error    3    Unable to copy file "C:\src\ImageViewer1.0\ImageViewer\\..\ImageViewer\StudyFinders\Remote\bin\Debug\ClearCanvas.ImageViewer.StudyFinders.Remote.dll" to "C:\src\ImageViewer1.0\Desktop\Executable\\\bin\Debug\\plugins\ClearCanvas.ImageViewer.StudyFinders.Remote.dll". Could not find file 'C:\src\ImageViewer1.0\ImageViewer\\..\ImageViewer\StudyFinders\Remote\bin\Debug\ClearCanvas.ImageViewer.StudyFinders.Remote.dll'.    C:\src\ImageViewer1.0\ImageViewer\ImageViewer_dist.proj    155    5    ClearCanvas.Desktop.Executable

Error    4    The command "c:\WINDOWS\Microsoft.NET\Framework\v3.5\Msbuild C:\src\ImageViewer1.0\Desktop\Executable\\PostBuild_dist.proj /p:SolutionDir=C:\src\ImageViewer1.0\ImageViewer\;SolutionName=ImageViewer;Configuration=Debug;ProjectName=ClearCanvas.Desktop.Executable;ProjectDir=C:\src\ImageViewer1.0\Desktop\Executable\;PlatformFolderPrefix=;OutDir=bin\Debug\;DistributionDir=" exited with code 1.    ClearCanvas.Desktop.Executable
 

Thanks, Stewart,

My first attempt was, indeed, with the 1.3 codebase (SVN trunk, to be precise) and it also failed, with 80 errors ( c.f. http://www.clearcanvas.ca/dnn/Community/Forums/tabid/69/aff/8/aft/13213/afv/topic/Default.aspx )

Pete or any other VS2008 pioneer -- I'd appreciate knowing what changes you need to make.

Thanks,

-Steve

I was able to compile and run the workstation using the ImageViewer.sln in VS2008 without any problems - it just converted over.  I haven't tried the ImageServer or RIS though

Back in March there was a flurry of posts that clarified some of the CC team's design decisions.  Now we have the trunk switched over to VS2008.  Has anyone attempted a plugin with a WPF view component?  I'd be interested in your experience.