What do you think of... The Parts Framework?
Parts, connection points, services (and dependencies), templates... What do you like? What don't you like? There's lots of gooey goodness to explore here, and we want to know what you think!
Things to think about:
- Does the parts framework make common development scenarios easier for you?
- What in the framework is unclear or confusing?
- What would you like to see added to the framework to better suit your needs?
- <your considerations here>
Happy postings!
Regards,
David
This posting is provided "AS IS" with no warranties, and confers no rights.
I'm having a problem seeing what the value proposition is of Acropolis over WPF user controls. Some parts feel like I'm seeing an MFC CDocument in a WPF world.
What is a part really supposed to be used for? Could you share some of the scenarios documents that describe why certain features exist? The help file and documentation don't do much for explaining why Acropolis instead of something else.
Acropolis Parts
An "Acropolis" part is a coarse-grained piece of business logic [...]. However, a part does have a user interface associated with it. [part of the Acropolis helpfile]
I do not like the fact that business logic associate user interface components. This is the upside down of the popular separation in logical layers [Larman04], [Fowler03].
e.g. UI -> Workflow, Mediation -> Business Logic
I see the separation of Part and the Part View more like the Supervising Controller pattern:
Factor the UI into a view and controller where the view handles simple mapping to the underlying model and the the controller handles input response and complex view logic.
Part View = view
Part = controller
Business logic = model
See http://www.martinfowler.com/eaaDev/SupervisingPresenter.html
In my opinion the business logic should only be implemented as Acropolis Services. These services can ideally be used for representing Facades (GoF Design Pattern).
[Larman04] Larman, C. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development
[Fowler03] Fowler, M. 2003. Patterns of Enterprise Application Architecture
Parts are meant to encapsulate some piece of re-usable functionality within an application. Since, by definition, they have a UI associated with them, they can be said to represent the visual building blocks of an Acropolis application.
By default, a Part consists of two components - the View, and the underlying Part component. The View encapsulates the UI and any UI-specific logic (i.e. ‘presentation logic’) whereas the Part component encapsulates any UI-agnostic logic (we typically use the term 'business logic' here but we really just mean any logic that is not specific to a particular UI implementation).
The key benefit that parts provide is the strong separation between the UI and any non-UI application logic. On top of this basic separation we can implement a number of interesting patterns, including MVC, MVP, Supervising Presenter, etc.
We shied away from adopting or promoting any one specific UI pattern since (at Martin Fowler aptly points out) these patterns are open to wide interpretation by developers, and there is no universal general purpose UI pattern that suits all scenarios all of the time.
For example:
A part can have multiple views. The desired view can be chosen at design time by the developer of the application, or at run-time by the end-user themselves. The canonical example here is the ‘graph vs table’ example where one part view can present data in tabular form, and another can present the same data in graphical form.
In this case, the part component could implement the model itself, or act as a controller for a model implemented within a service. Which approach you take might depend on whether you want the part to be self contained or not, or on the level of granularity or separation of concerns you want to achieve.
Thanks,
David.
My feedback…
Many years ago I read about the concept of a Software IC (I believe it was in Byte Magazine). The concept was to mirror the way that transistors were built into Integrated Circuits that have defined interfaces (pins) and defined functionality. I see the "part" approach as another attempt to bring this concept to life. If we can produce reusable software components we can greatly reduce the time needed to create software.
This concept has been chased for years with limited success. The .NET Framework was a fantastic step in this direction. I can look up a series of XML related classes with well documented properties, methods, and events (think of the pins on a 555 Timer Hardware IC) and "wire" these together into a working program.
"Parts" will allow us to create software components that are further abstracted from the .NET Framework Classes. But, how many times do we already subclass the classes in the .NET Framework because they just don't quite do what we want them to do. Can Acropolis actually help us to create "reusable" components that can be wired together and improve software development?
Acropolis does encourage us to use some very good practices. Creating interfaces to connect the parts together is a good practice. But, can't we do all of this by using these practices to create our own classes? Maybe Acropolis is needed just to encourage programmers to more closely follow good practices.
What about WPF? I love the declarative nature of XAML. Rather than writing code let's just tell the framework what we want. I want a tool that allows me to concentrate on declarations of functionality not syntax. This tool should have enough self diagnostics and self awareness to prevent “bugs”. I believe this is the future of software development.
What else should Acropolis do? Basically, I believe that software development is an iterative process that can never be fully planned before we start coding.
1. Declare what we want
2. Look at what we have created
3. Loop back to step 1
I use VStudio because I can write code, press F5, see what happened, then go back to writing code (those wonderful .NET Classes don’t always do what we think they will do). I am studying Acropolis further to try to discover how it will allow me to better “evolve” software.
David,
thank you very much for your explanations on UI patterns in Acropolis. I was looking for some insight on how this topic is handled in Acrpolis. However, looking at which Part-View-relation I can currently implement with Acropolis, and what on the other side is the usual way of View-Presenter-relation in CAB, I doubt that Acropolis is not promoting a specific UI pattern, as you said.
One of the things I like about SCSF/CAB is that it encourages you not to use any kind of observation pattern between view and presenter. The presenter calls - via an interface - methods on the view, and the view calls methods on the presenter. That's clear, easy to understand, and most important of all: easy to unit-test. No problem having a mock framework implement the view interface and write a unit test for the view. In my opinion, this is very near to the "Passive View" pattern in Martin Fowler's terms.
So, while in CAB the presenter does not know *which* view exactly it actually controls, it very strongly assumes that there is *some*. A part in Acropolis, however, is UI-agnostic, so that it not even knows whether there is any view at all. All it can do is cry out loudly and hope someone is listening.
Yes, listening: observation pattern is back, and it is everything. All connection points we see so far build upon it. I would very much like to see how Acropolis parts are supposed to be unit-tested. By now my impression is that it would be much harder again than it is with presenters in CAB. I can't see how I could easily wire up a mock object to the connection points of a part.
A small example: let's think of a command handler where I want to give the user some feedback on how the command was executed, that it went ok or produced some errors or warnings. Quite easy with CAB: simply define an appropriate method in IView and call it from the command handler. The nearest thing in Acropolis (if I haven't missed something) would be a ComponentNotification. But what if I would not only want to hand over the message text, but also some kind of error level and some kind of hint which element caused trouble (to let the view set the focus, e.g.)? I would then need to invent some way to put it all in the single parameter the ComponentNotification has.
Since you said Acropolis would not promote any specific UI pattern I would like to know how I could implement the CAB-style / passive view pattern. This would also be helpful to get more confidence in the mysterious "migration path" from SCSF/CAB to Acropolis that was promised. I do hope that the answer will not be similar to "define a ComponentNotification for each method you would have had in IView, each with a transport object to carry all the parameters, and a ComponentCommand for each method the (CAB-)view was calling on the presenter". Maybe there will be other kind of connection points that basically offer to set and retrieve interface-typed properties? (Would be very similar to a service dependency, but service dependencies are not supposed to be used between a part and its view(s), are they?)
Regards,
Matthias
Hi,
It is very hard to give any valuable feedback right now IMHO, because the amount of documentation is very low. People don't exactly know what Acropolis is and what it is capable of. Just read some postings here on the forum and it becomes immediately clear that everything related to Acropolis is vague to most of the people. The class reference isn't even documented. And I also think that the current videos and samples are not really showing the capabilities of the Acropolis framework right now (I hope).
I know documentation is not a topic where you want to invest in while still in the development phase, but I can't imagine, you haven't some kind of architecture or requirement specification document. Releasing that (or a part of) will allow people to give valuable feedback.
The only way to retrieve information right now is using Reflector to look what's inside the black box, but unfortunately I don't have enough time to do so.
Best regards,
Benny
@David: I had hoped you would find some time to give at least a short answer on my posting above, concerning unit tests in Acropolis and the relation between CAB and Acropolis on the UI pattern level. Maybe it only slipped through?
Matthias
