First Draft Description for Scenery Design Tool

[lmoelleb]

Are we going for MVP (Model View Presenter), MVC (Model View Controller), or BBM (Big Ball of Mud)? My preference is clearly MVP (both from an architectual point of view, and because this is what Microsoft Smart Client Factory gives us per default).
I am afraid I am simply too old to be part of a BBM project - it is too frustrating on the long term.

PS: Just to warn you guys - I have abselutely no tollerence for incorrect use of upper and lower case in the code, so if you get it wrong, be warned that I WILL let you know.

 

[nickw]

PS: Just to warn you guys - I have abselutely no tollerence for incorrect use of upper and lower case in the code, so if you get it wrong, be warned that I WILL let you know.

Lars.... you wouldn't be one of those moody coders I have heard so much about LOL

I agree with you though, attention to detail is key.

 

[scruffyduck]

Are we going for MVP (Model View Presenter), MVC (Model View Controller), or BBM (Big Ball of Mud)? My preference is clearly MVP (both from an architectual point of view, and because this is what Microsoft Smart Client Factory gives us per default).
I am afraid I am simply too old to be part of a BBM project - it is too frustrating on the long term.

PS: Just to warn you guys - I have abselutely no tollerence for incorrect use of upper and lower case in the code, so if you get it wrong, be warned that I WILL let you know.

Well I think I am too old for Mud Wrestling also.......

What are the pros and cons of MVP and MVC - I have seen an article which appears to depreciate MVP - http://www.martinfowler.com/eaaDev/ModelViewPresenter.html


Lars - would you like to share your standard for naming conventions please? I am sure we all do it differently and I know I get my Pascals and Camels muddled up

 

[lmoelleb]

Well I think I am too old for Mud Wrestling also.......

What are the pros and cons of MVP and MVC

The Controller only "controls" the data model. The Presenter also controls the view. The Presenter is what the Microsoft Patterns and Practices group use in the client factory, and it is pretty will supported (the stupidity work of creating it is done for you). More or less enough for me.

- I have seen an article which appears to depreciate MVP - http://www.martinfowler.com/eaaDev/ModelViewPresenter.html

As far as I understand it it's not really depreciating MVP, just realizing there are two versions. One where the model and the view are not connected in any way, they only communicate though the presenter, and one where the view is "allowed" to read the model directly (and subscripe to events). I tend to prefer the latter to get a bit less plumbing code.

Lars - would you like to share your standard for naming conventions please? I am sure we all do it differently and I know I get my Pascals and Camels muddled up

Don't worry, I am not so crazy I insist everyone follow MY standard... I insist everyone follow Microsoft's standard

Have a look here:
http://www.gotdotnet.com/team/fxcop/

it might be worth running now and then. The specific page regarding case used is here:
http://www.gotdotnet.com/team/fxcop/Docs/Rules/Naming.html

PS: Yes, I am a grumpy programmer. Too much plumbing and low level programming in too many years - can you turn out any other way?

 

[scruffyduck]

Hi Lars

Thanks for the explanation - I have been doing a bit of research on MVP and it certainly makes a lot of sense to me so I agree that we should work with that design pattern.

OK agreed on MS standards - I have used FXCop myself, but working on my own I guess getting conventions right has taken a lower priority. Also coming from a background of using a case insensitive language does not help.......

For team work we need standards otherwise we will get straight into mud wrestling

I think we need is a FAQ. We are getting odd questions like what is the difference between C++, C# and so on and maybe a FAQ would be a good way to go. Should that go in the Wiki? That way we can all update it

 

[lmoelleb]

Jon,

Are you talking about a FAQ concerning tools programming itself, or the standards used for this specific scenery design tool? I think both might be needed, but for this specific tool it is not as much a FAQ as a simple list of coding practices/designs used (so nothing about WHAT we are going to build, just how we do it). Something like:

• Implemented in C# 3.0
• Microsoft Smart Client Factory based client.
• WCF based server (TODO: Is there a factory we can use)
• MVP as done by MSCF.
• WinForm controls, main 2D map view in (DirectX|WinForm|OpenGL|WPF)??
• Observer pattern.
• The view is allowed to read and subscripe to the model directly, but can't change data.
• While some exceptions will be allowed, FXCop rules should be followed, specifically for public interfaces (we need to look into this as we get going and agree on what we ignore).
• We do not use Strong Names (exception to FXCop) to make it easier to load third party components.
• Avoid Dll import as far as possible. When used, assure it will work with 64 bit as well.
• Limit dependency on 3rd party COM components to ease installation process.

a FAQ could then explain what it all means
Any progress on getting the WIKI page updated. I have lost track of the feature list already.

 

[scruffyduck]

I was thinking about the FAQ in general rather than specific to the project. I agree that we are talking about standards to be used for the project.

I have not put anything on the Wiki since I recall Arno/Nick saying that they were changing the software and not to put anything up at the moment. I have been updating the draft description at the top of this thread with stuff as we talk about it though.

One question comes to mind on tools, I, and I guess some of the other guys, use the Express Editions of VS2005 (I can't justify the cost of VS2005 and so far everything I need to do can be done with C# Express). Clearly these have limitations and I don't know if they can be used with some of the frameworks such as Smart Client Factory, of the NET 3.0 Beta Framework?

 

[lmoelleb]

Smart Client Factory and C# 3.0 should work just fine on Express - at least it is listed as supported on:

http://msdn.microsoft.com/windowsvista/downloads/products/getthebeta/default.aspx

Updaet: It seems Guidance Automation does indeed not work on Express, which means that it is hard for users of Express to add modules (they can still work on the modules etc once they are created). I would consider it as a major setback not to use the structure of WSCF so I would still use it - and then let a user with standard or better VS create the modules if required (it CAN be done manually as well).

 

[scruffyduck]

Thanks Lars - my reading of the requirements for the Client Factory is that it needs XP Professional and VS2005

+Microsoft Windows 2000, Windows XP Professional, or Windows Server 2003 operating system
+Microsoft .NET Framework 2.0
+Microsoft Visual Studio 2005
+Microsoft SQL Server 2005 Express Edition or SQL Server 2005
+Guidance Automation Extensions Technology Preview (June 2006 Release for Visual Studio 2005)

I guess that not all developers working on this will need the Factory or will they?

dotNET 3.0 looks OK I am installing that now to see if I can work with it in C# Express.

 

[scruffyduck]

I just noticed that the Wiki Entry is read only. Nick we have changed the name and so on. If we are getting a new Wiki then perhaps we can delete the current AFCADX entry or rename it to Scenery Design Suite X?

 

[arno]

Are we going for MVP (Model View Presenter), MVC (Model View Controller), or BBM (Big Ball of Mud)?

I'll have to do some reading before I can answer this one, these terms are quite new to me. So I'll come back to this later this evening.

I was thinking about the FAQ in general rather than specific to the project. I agree that we are talking about standards to be used for the project.

I don't think something like programming conventions should be in a general FAQ on this forum, every programmer can decide on that himself. Such a thing is only useful for within our new tool project.

I don't think the purpose of the general forum should be to learn people how to program like we want to see it, it should help them solve their problems .

If we are getting a new Wiki then perhaps we can delete the current AFCADX entry or rename it to Scenery Design Suite X?

I have added a page to the new Wiki for the requirements, so we can put it there:

http://www.fsdeveloper.com/wiki/index.php?title=SDSX_Requirements

I will also create a subforum for the discussions about this new tool, I think we should not pollute the tools programming forum with very specific discussions about this tool.

 

[scruffyduck]

I don't think something like programming conventions should be in a general FAQ on this forum, every programmer can decide on that himself. Such a thing is only useful for within our new tool project

Agreed, my thought was more something along the lines of the Scenery Design FAQ over at AVSIM - more of a help to people who want to get into writing addon programs for FS?

I have added a page to the new Wiki for the requirements, so we can put it there

Thanks Arno

I will also create a sub forum for the discussions about this new tool, I think we should not pollute the tools programming forum with very specific discussions about this tool.

Thanks I think that will be a big help

 

[arno]

Agreed, my thought was more something along the lines of the Scenery Design FAQ over at AVSIM - more of a help to people who want to get into writing addon programs for FS?

Sure, please create whatever you want. But once it turns into a real tutorial, I think it should be on the Wiki. But a quick Q&A thread would be very useful as a sticky.

Thanks I think that will be a big help

Done, I have also moved all posts related to this project to the new forum.

 

[lmoelleb]

Thanks Lars - my reading of the requirements for the Client Factory is that it needs XP Professional and VS2005



I guess that not all developers working on this will need the Factory or will they?

Nope, they do not need the Smart Client Factory - they can in theory do everything without it, but in reality it should probably only be people with access to the Smart Client Factory that adds new modules.

 

[arno]

Thanks for the explanation - I have been doing a bit of research on MVP and it certainly makes a lot of sense to me so I agree that we should work with that design pattern.

Same for me. I have done some reading on it and it sounds like a good idea to me to use this design pattern. Using such a pattern is new to me, although I have tried to implement some of the ideas behind it before. So I am looking forward to learn more about this.

 

[scruffyduck]

I agree with that Arno. This has already been a very valuable experience for me. I knew about design patterns, of course, but somehow I never got my head around using them in a program until now.

I have been looking at the Observer Pattern which Lars mentioned. It is very easily implemented in dotNet and C# using events and delegates, which I have used a lot, but never really though about creating it in the way the observer pattern describes it.

 

[scruffyduck]

Nope, they do not need the Smart Client Factory - they can in theory do everything without it, but in reality it should probably only be people with access to the Smart Client Factory that adds new modules.

OK but I would not want to limit the ability of people to contribute to this development because they do not have VS2005 or XP Professional.

 

[lmoelleb]

OK but I would not want to limit the ability of people to contribute to this development because they do not have VS2005 or XP Professional.

I do hope you plan to require at least VS2005 Express

If you have not used these patterns before, I have to warn you that you are in for a bit of a rough ride initially simply finding your way though the source code. It starts out pretty complex, but unlike the Big Ball of Mud pattern, the complexity doesn't grow exponential as the functionality grows, hence the end result will be simpler.

 

[scruffyduck]

I do hope you plan to require at least VS2005 Express

Yes

If you have not used these patterns before, I have to warn you that you are in for a bit of a rough ride initially simply finding your way though the source code. It starts out pretty complex, but unlike the Big Ball of Mud pattern, the complexity doesn't grow exponential as the functionality grows, hence the end result will be simpler.

Rought rides I am used to - so much to learn and so little time

 

[scruffyduck]

I have added version 0.2 of the design document in the first post of this thread. It is currently an rtf document.