With a header like that I guess I am bound to fail – but such a sample is missed. The target audience for a sample like that is:
- Myself and others at CapableObjects needing to check a thing or two
- New evaluators that want to get a feel for the ModelDriven Approach to life
- Die hard ECO Developers that has wandered away from their comfort zone
- Developers starting a new project – and see no reason for not getting a head start by copying the sample and removing the things they do not need
- Developers describing ECO to other developers – our best and most valued sales channel
- Bug reports for ECO may be submitted as a failing unit test on the sample (I guess?)
I have decided to call the sample EcoSolutionShowcase. My intention is to create this sample in iterations and write as I add new things. Feel free to come forward with ideas that you want to have the sample zooming in on.
This first iteration of the sample shows what I personally felt a strong desire to describe initially. The sample is included in ECO daily builds after today (2011-09-26).
ECO is a big framework, but using it must be simple or it will not be adopted by stressed developers that simply will not believe what ECO can do for them unless they see it for themselves.
When I describe how I normally develop and then review what I have said or written – I always see that I cannot really convey how I totally mix, slice, dice and jump back and forward between the different steps involved; planning, modeling, ViewModels, deciding UI, compiling, testing, writing actions, updating the database, back to modeling. I AM NOT CONSISTENT OR STRUCTURED, I AM HUMAN. I need a tool that follows me – not a tool that dictates the order how I attack the complexity at the heart of software (to quote a book that seems fairly popular, DDD ). So keep that in mind when reading this; it is not constructed in the same order it is described, it is not done in one iteration, it is not done as it is – there will be more – there is ALWAYS more, there is no additional script on the side that I follow.
Planning with the Enterprise Architecture information tool
Having a clue on what the system should do is always smart. Often it might take you 30-60 minutes talking to the main stakeholder to create your own mental picture on what the system is… Great – the thing is that mental pictures are hard to project onto a surface so that someone else can get it without constant questions – questions that keep you from your work.
Another thing I have found when doing SUPER-BIG-and-RECURRING-context-switches is that I forget… Sometimes I forget so much I cannot recall that I knew that I ever knew. I still have a super memory that I am really happy with – I remember more than the average guy – but still given enough BIG-RECURRING context switches can make my brain drop stuff in write only memory (wom? does that even exists? Cannot think of any use for it… Maybe to simulate forgetness in robots?).
I use the EAInfo tool in Modlr to get the Enterprise Architecture screens to present what the different actors are supposed to do in this particular domain. Doing so triggers my thinking into dividing the the solution into different parts – I have found that if I do not do this work I tend to underestimate the work that needs to be done. And if I have underestimate I sort of push myself into a corner where the stress is really high – better to get a grip early – much less frustrating to answer all the questions about progress when you know the goal and where you are now.
But as I said – I do NOT do all the planning at once – I skip back and forth – adding information as it comes naturally. This way I never need think really hard and long on one specific thing, and I never need to keep a separate list of things I shall remember to do later – I just do them when I feel I have the information and it comes naturally.
If you skim through the process descriptions from the screen dump above I think you too get a pretty good overview about what the EcoSolutionShowcase domain is all about (saves me the trouble of telling you and that is precisely how you should use these screens).
The sample is NOT about the domain – the sample is about ECO – so do not get too excited. This model will do nicely for starters.Whether the sample in the end will describe Versioning or not I would rather not decide now – but it probably will.
I like my multilink endpoints to end with a plural “s” – so that the link from ProjectGroup to Project is named Projects instead of Project. Of course I can name the association ends explicitly but since this is my general rule I just set the PluralSuffix property of the Package to “s”.
I also find it very useful to have a common super class for all my modeled classes – this common super class I attribute with changetime, createtime and a guid. I have found that I always need this sooner or later – especially if integrating with other systems. Of course I can set the super class of all my added classes to this CommonSuper, but since this is my general rule I just set the “Default Superclass” property of the Package.
One thing I want this sample to show is the different UI-strategies you can use with ECO. Another thing is Persistence server that communicates with the clients over WCF. I really want the Persistence server to support the ECO concept of synchronization so that the different clients can view the same information at all times real easy.
When it comes to produce UI there are so many options that I will not do every strategy on every UI technology. If someone were to force me to choose a UI technology that the sample shall focus on I would say WPF – it feels modern and it is easy to debug (silverlight starts slower and does not allow for edit and continue).
Silverlight is however really cool and I want that in there as well. Since Silverlight has its own runtime (not the standard .net) there are special challenges to get the shared resources like the Model into both Silverlight runtime and the normal .net runtime. These challenges are handled in this sample.
The sample solution has the following projects:
EcoSolutionShowcase.PServerIis – this is the persistence server. In it is original configuration I have set it up to use Xml persistence – but I will show the switch of PersistenceMapper to handle OR-mapping with SQLServer and database evolution.
EcoSolutionShowcase.Asp – this shows the ASP.NET Autoform, the AutoViews based on ViewModels and also host the Silverlight client
EcoSolutionShowcase.WinForm – WinForms is a reminisce for the “good old days” – still a robust and frequently used UI platform. Here we show the EcoSpaceDebugger and the winforms implementation of a AutoView based on a ViewModel. I will probably show the standard ECO-winforms approach with binding to handles as well.
EcoSolutionShowcase.WPF – The declarative UI approach – cool and rather a shift in thinking compared to a traditional UI. In this project I will show the whole scale of very, very declarative system building with WECPOF and then thru to the least sophisticated approach binding straight to the domain model.
EcoSolutionShowcase.WPFBrowser – Same as WPF, but executed in a browser. Brings little new, but has some security considerations so I better leave it in.
EcoSolutionShowcase.SilverlightApp – Silverlight is just like WPF only it does not really work . That was a bit harsh – I like silverlight but it gets me very frustrated sometimes. ECO for silverlight works very well and silverlight forced us to solve the a drawback with ECO from the get go : the locking of the UI thread while loading data from server. The solution surface in ECO as the AsyncSupportService. The AsyncSupportService will work in WinForms and WPF also.
The sample will not cover ECO-Windows-Phone-7, I will come back and describe that in another post when the Mango-update is out.
And we also have these projects:
EcoSolutionShowcase.Model – To hold the derived code from the model.
EcoSolutionShowcase.SilverlightModel – This is a silverlight project that has the same function as the EcoSolutionShowcase.Model project. Nothing new here.
EcoSolutionShowcase.EcoSpace – holds the unique EcoSpace type for our model driven project and also points out the PersistenceServer WCF endpoint
EcoSolutionShowcase.SilverlightEcoSpace – same purpose as EcoSolutionShowcase.EcoSpace but for Silverlight.
Focusing on perspectives
To get started at least I must take on an actors/users perspective. What do we need first?
So if that is what we need to do then I can create the ViewModel that has the data and actions for this:
And since I want to use WECPOF and AutoViews on my ViewModel I also give the ViewModel UI-hints on how to display the data (purists tend to puke here but pragmatics tend to clap their hands – ECO allows for both camps):
Testing the first User interface (UI)
With minimal effort I quickly want to verify that I have a strong connection with my computer and that me and my computer will work as a team to solve domain specific problems. At this point I am looking to determine whether the computer will help me or if it will act all stupid and understand nothing about what I have just told it: DomainModel+runtime-UI-engines+ViewModels+UI-hints+DefaultActions+Persistence+Communicate-with-WCF-over-http.
WECPOF Silverlight comes up, I enter some data and press save:
WECPOF WPF-forms comes up:
The use of single AutoViews in xaml comes up:
The xaml standard bind to code generated viewmodel comes up:
The AutoView in the winforms project comes up:
The EcoSpaceDebugger comes up:
The AutoView in ASP.NET comes up:
The ASP.NET AutoForms comes up:
Nice – my computer and I are friends – together we can focus on the real problems – and I can trust that the infrastructure is there for me – what ever type of UI I choose to use.
I will end this post here and create new posts for different aspects that I want to describe.