.NET Megademo

So what have I done to implement the functionality for iteration 1? Let me remind you what it was (from the iteration plan page):

• Main windows allows selection of various editable data types
• Data of selected type is shown in list and can be edited

Let’s start looking at the functionality from the perspective of a user. This is not necessarily the order of implementation (although it may be, nothing wrong with that), but I find it quite natural to start that way – after all, we’re all users of more software applications than we’re developers of.

UI Elements

For visualization purposes, according to the requirements, we need three things:

• a main window
• an area in the main window that lists the “various editable data types” and allows the selection of a type
• an area in the main window that shows a list of data of a specific type and allows to edit that data

 The class DevExpress.Megademo.UI.Win.TypesNavBar  implements the visual list of editable data types. It’s a simple control that derives from the NavBarControl (from our XtraNavBar product) and initializes itself automatically with the correct types (see Searching for Types below). It raises an event when the end user clicks on one of the type entries.

The ViewContainer is a very simple class based on a UserControl (well, an XtraUserControl actually, for automatic styling), which can take a TypeView and show it. This will have to be generalized in the future, so that other types of controls can be shown inside the container.

With the help of the UIConnector component, these two visual elements can be hooked together, and they can also be assigned a ViewManager, which has the job of finding the right view for a type. Right now there’s only one such view, implemented in the GridView class, so the job is extremely simple at present. Nevertheless, this implements some important flexibility plumbing for future extensions.

Implementation of the actual list view and editing functionality is very basic at the moment. The GridView is the view that’s used for all the types and it simply creates a data collection of the given type and hooks that up to a GridControl (XtraGrid). It does use a UnitOfWork (XPO) to encapsulate data changes, and it has two buttons that allow the end user to confirm or roll back any changes he’s made – there’s some detail work to be done here, and some of you have already noticed that the delete functionality doesn’t currently work. More on that in later posts.

Searching for Types

To allow the UI components to find those types that are supposed to be available on the top level of the user interface, the attribute RootType can be used to decorate persistent classes. The class RootTypeFinder encapsulates an implementation of a search engine that can find the relevant types given an assembly. This is currently used by the TypesNavBar. Nothing complicated about it, really – just some reflection to figure out which of the types in the assembly have the RootType attribute applied to them.

So this is it – a summary of the implementation for iteration 1. Please feel free to ask questions if you want to discuss my approaches, but remember it’s early days…

This post is related to the iteration 1 status of the project, which has been published here.

Structure of the solution

Currently the solution contains six projects. Three of these belong to the demo application: DevExpress.Megademo.Data has all the business classes and the data management related helpers, DevExpress.Megademo.UI.Win holds the Windows Forms specific classes (no, I don’t think I’ll create a non-Windows Forms frontend, but splitting this off seems like good common sense) and Megademo.Win is the actual Windows Forms frontend application. I consider this a rudimentary structure – I’m making no effort to keep the UI layer independent from the data layer, for instance.

The other three projects are test projects. DevExpress.Megademo.Data.Tests has the tests for DevExpress.Megademo.Data and DevExpress.Megademo.UI.Win.Tests, not surprisingly, has tests for DevExpress.Megademo.UI.Win. These are (and are going to be) mainly unit tests, which is why the separation per tested assembly seems like a good idea – in this project, I might not be too particular about the idealistic differences between unit and functional tests, but the separation between tests for one or another assembly seems like a useful restriction. The last assembly, ApplicationFunctionalTests, provides a container for tests that are functional and on the application level (duh!).

Requirements

The requirements to build the three “application” projects are simple: an installation of DXperience 6.2 is needed. The binary download is built against 6.2.3, but the projects now have the “Specific Version” flag set to False, so it should theoretically be possible to build against any other 6.2 release easily. I’m saying “theoretically” because I haven’t actually tested this - of course the functionality could be different (I hope it isn’t, though, because our target is to have no functional differences between minor releases).

Building the complete solution, including the test projects, requires NUnit and NUnitForms. You can download these two tools here:

• NUnit: http://www.nunit.org
• NUnitForms: http://nunitforms.sourceforge.net/

Now, there’s a certain problem with the references, specifically those for NUnitForms. If you have a basic installation of NUnit, the assembly NUnit.Framework, which is referenced by the …Data.Tests assembly in the solution, should be picked up from the GAC automatically. But the NUnitForms installation, if you download a binary file (my version is 1.3.1), comes as a zip file, and obviously the references need to be modified to point to the place where you install/copy the assemblies on your machine!

Here’s what you have to do to make the test assemblies ApplicationFunctionalTests and DevExpress.Megademo.UI.Win.Tests build:

• Download version 1.3.1 of NUnitForms from the URL above and unpack the archive somewhere on your computer.
• For both test assemblies (again, ApplicationFunctionalTests and DevExpress.Megademo.UI.Win.Tests), replace the references to NUnit.Framework and NUnitForms so that they point to the correct assemblies on your own system. You need to reference both assemblies from the installation directory of NUnitForms – NOT one of them from the GAC and the other from the NUnitForms installation.

This is a somewhat stupid problem – I’ll try to come up with a better solution in the future. Anyway, that was it. If you have any other problems, please don’t hesitate to comment here or contact me otherwise, so we can make sure the demo is really easy to use.

I’ve finally found the time and done it! So, two downloads are available for iteration 1:

• A binary archive of the current application
• The current source code

If you find yourself wondering what this is all about, please go to this page and read the posts on the .NET Megademo blog – start at the bottom to get the story from the beginning.

This is what the application currently looks like – yes, I know, we’ll go for smashing looks another time :-)

 To compile the sources, you’ll need DXperience 6.2 installed. If you also want to compile the test assemblies, you’ll need NUnit and NUnitForms… with NUnitForms the problem is that their binary release comes with a specific version of NUnit that has to be used if your normal version is not the same. Well. Sounds difficult but it’s really not that bad – I’ll post another article here soon to describe the whole setup exactly, something that needs to be done anyway at the start of the project. For the time being, if you don’t get the tests compiled on your own, just leave them out :-)

I’m going to do two other posts here soon (this week, I hope):

1. Description of the project setup and requirements for building it
2. Explanations about the code I’ve written for this iteration

I don’t want to leave the impression that this project is dead before it even started, so here’s a quick update.

It is as it usually is with this kind of thing: as soon as the decision has been made to start such a project, lots of other things are suddenly more important. I haven’t had very much time during the last two weeks, but I’ve managed to get halfway through iteration 1 nevertheless (see here for what iteration 1 is). The better part of next week I’m going to be in Germany for Basta! conference, were Developer Express are exhibiting (and I’m speaking on the model based architecture in XAF – come see me there if you happen to be around), so I guess there won’t be much time again.

Anyway, as far as I’ve come, things are going well. I’ve implemented a simple type searching system that finds those data classes that are considered relevant for top level UI display, and a navigational element in the UI can already configure itself to do the actual displaying. More on this when I finish iteration 1 – maybe towards the end of next week, if I’m lucky.

To keep this blog active, a short notice – I have been doing some concept work on the project, but a number of other things have prevented me from really digging into it deeply so far. Things will probably progress rather slowly over the next few weeks, as there are so many other things in the pipeline… I’ll try to find the time to work on the project as much as possible, promise!

The good news is that I’ve talked to Julian about the idea of publishing webcasts for the Megademo project, and we’re going to do some interview-style videos. It’ll be a few days though – please bear with us.

So, I’ve come up with a first plan for a “1.0” release of the demo. I’m not sure whether it’s a good idea to use version numbers for the “releases” of the demo. A version number 1.0 implies a certain amount and stability of functionality, and that’s not really what I have in mind here. The plan I’m proposing here is merely a summary of a number of steps I’m going to take – and because I don’t want to plan all imaginable steps at the same time, I’ve simply tried to find a useful collection of steps that group together nicely.

I’ve also been thinking about the manner in which I’m planning here, and I think that this kind of overview is a good idea in the case of this demo. The planning methodology that I think I’m closest to is XP, but then I’m not going into all the details. I’m going to talk about “iterations” in the list below, so it would make sense to call the whole thing a “release plan”, but then I’m planning on making interim versions available after every iteration, and I'm not prepared to set a fixed time for an iteration either. In short, I believe the special situation that this application is being developed in – by a developer for the perusal of other developers, not so much for actual end users – justifies a pretty relaxed handling of planning procedures. I also really want to be flexible, so if additional steps, samples of alternative approaches or similar efforts are required at any time, I’ll just push them in somewhere.

Iteration Plan

General considerations

Similar to a real-world project, the basic functionality is not the only consideration about an application. There are more general requirements such as "it should be easy to recognize runtime errors" or "the application should run in a multi-user environment". There are also guidelines for a development environment, for instance for unit and functional testing. I intend to incorporate logging into the application and keep the multi-user requirement in mind, and I also plan on creating unit as well as functional tests. Please let me know what other "general requirements" you can come up with, maybe they're worth including.

Tools

I’m going to use NUnit, NUnitForms and TestDriven.NET to facilitate unit and functional testing, later also NUnitASP. You will have to download and install the first two if you want to compile the source of the solution(s), but I will provide detailed instructions to do that when I make the first download available. For logging I will use log4net, where the same thing applies. As far as I can see, log4net is going to be the only library not from DeveloperExpress to be used in the application – I don’t want to make things more complicated than necessary, but logging is a topic into which I don’t want to delve myself while writing this application.

I’m in the process of giving some in-depth thought to the structure of the demo I’m going to create, and one question I’ve been thinking about is “Do I want to create a reusable framework or a disposable application?”. A question that I’m sure everybody has been asking himself at some point. In some comments on the previous blog articles people have already been assuming that there will be some kind of underlying framework to the solution, so apparently there’s a certain expectation.

To be a real-world application, I believe a certain amount of reusability in the concept is inevitable. At least I hope it’s commonplace – every programmer out there should be creating his applications in a way that allows certain modules in them to be reused. I’m using the word “inevitable” here because I’m coming from a different direction with this demo: I don’t really care whether the modules are reusable or not, because in the end it’s just a demo. But I want the demo to be similar to what real developers work on, and the assumption that reusability is unneeded wouldn’t be realistic.

So how far will this go? Obviously, a full concept of a reusable application framework is a bottomless pit in terms of effort involved. And in the end the demo might look a bit like the eXpressApp Framework (XAF) we are already creating here at Developer Express. That’s not the purpose of the demo, and there’s also no time for such an elaborate approach. So certain things will have to give.

I believe the best approach for me to take is to do roughly the same thing that a “normal” application developer would do. In certain areas reusability is a good thing and I want to go for it. As an example, it will probably make sense to use a common user interface part for representation of various data types in similar manners – like a grid, for instance, combined with certain user interface elements. It might also make sense to enable automatic creation of editing forms for detail data, we’ll see later whether we actually want that or not.

But as an example for something that most people probably don’t bother doing, let’s mention the topic of UI independence: most programmers do not, during the course of developing a certain application, create a whole intermediate library of UI elements, so that the same application can run seamlessly on Windows Forms and ASP.NET without writing any specific code. Usually, the customer requires either a Windows Forms application or an ASP.NET one, and if he actually needs both, the requirements are not usually precisely the same.

Of course there are probably some of you who have done UI independent frameworks, and I’m sure there are many arguments why it is a desirable thing. But it’s not a normal part of a development effort, unless there are specific requirements to that end. XAF does it, but then that’s because we target a lot of different developers with that kind of elaborate framework. Anyway, just an example – I’ll need to make cuts somewhere with regard to the framework thing, and that’s one example of where I intend to make them. What do you think?

Many of you have provided feedback on my original post by commenting on the blog or sending me e-mail, I appreciate that. This post summarizes my comments on some of your annotations – if your own comment is not mentioned specifically, that doesn’t mean I haven’t seen it, but rather that it was so clear it didn’t need any clarification or reply :-)

Lu. Po. et al.: Please, please, use XPO…

I will certainly do that, sorry if it sounded as if I wouldn’t. I was merely giving an example for the kind of information that would perhaps not be in the demo, even though many may find it interesting (ADO.NET)

Erick Sasse et al.: … now we need a VCL MegaDemo…

I see where you’re coming from, but I don’t know if such an effort will be made in that area as well. Please feel free to ask our support guys about it.

Several people: Documentation is very important

I hear you, and of course I agree. On the other hand let me point out that disagreements about documentation seldom come from disagreements about this simple point – nearly everybody agrees that documentation (and good documentation at that) is important, only the definition of “good documentation” is a pretty subjective thing.

For the .NET Megademo this means two things (from the top of my head, and with reference to feedback given):

1. I don’t have any general rules about code comments, but I tend not to comment if I find it “not necessary”. You will encounter methods, and probably classes, without comments. Of course, given the nature of this project, if you actually have trouble understanding something, feel free to point it out and I’ll make sure it’s explained and documented. But don’t expect me to comment everything as a matter of principle.
2. The documentation for this project, in the form of this blog or whatever other form, is not going to reproduce content that is already published elsewhere. I do believe that most of our existing product documentation is pretty good and complete. The purpose of this project is to show how things go together, and the documentation should illustrate the steps I’m taking, but things like the detailed description of a specific option will be left to the respective product documentation, as far as possible.

Trevor Westerdahl: I would prefer the XAF be entirely separate.

I expect that the XAF part of the demo will be pretty separate from the non-XAF part, yes. It will be interesting to show how the same class definitions can be used, given that XAF it based on XPO itself, but we can’t mix the layers above that between XAF and non-XAF approaches.

DeveloperK: CodeRush […] isn’t as amazing as I expected […] because I’ve never seen […] how to use the products effectively

CodeRush and Refactor! are the two products that have already been documented with screencasts extensively. Please see here: http://www.devexpress.com/Products/NET/IDETools/CodeRush/Training.xml

Several people: We want screencasts! (paraphrased)

Thanks for your input, it is very valuable. I can’t promise anything yet, but I’ll try to find a way – I agree that screencasts could offer that little bit extra that would let them understand the implementation more easily.

Somebody by e-mail: Make sure you include XAF! (paraphrased)

I will. Of course it’s a part of the demo purpose to show both sides – creating an application from scratch as well as using our elaborate XAF framework.

First of all, thanks to everybody who commented on my first post to this blog, I appreciate it. I’m not (yet) going to make any decisions based on the feedback, but one thing stuck out from all the rest, and so I wanted to post again on this specific topic: screencasts of the process of building the application were requested by some of you.

Now I have to admit I’m a bit confused by that idea, mainly because I’m having a bit of a hard time imagining how this will work.

Of course we have a number of screencasts for various purposes on our web site and even in our documentation, but it seems to me that these all (and each) serve a particular and well defined purpose. For instance, such a screencast might show how to perform some specific configuration work in one of our controls, or it might show Mark hacking around in VS demonstrating CodeRush features.

Now how can that technology be used to demonstrate the process of writing a whole application? As far as I can see, the writing of an application involves a number of tasks. Let’s have a look at those and see how they lend themselves to screencasting.

• Pondering design decisions. Not a likely candidate. You guys want to watch me think? (Or even worse, watch my computer screen while I think?) :-)
• Typing code. A semi-likely candidate, but I really can’t imagine somebody watching me for a prolonged period of time while I’m typing… Of course it would be possible to simply record my coding sessions, maybe including some of the pondering from above, babbling along a bit (which I tend to do anyway) – but then there’s a pretty big overhead involved in editing these recordings and making them available, and are you really going to watch a session of a few hours? More than once?
• Clicking around in Visual Studio, doing work in the designer. In practice, probably mixed in with the coding above. Also a similar likelihood rating as above.
• Debugging. Well. I don’t even like to watch myself debug something. It’s just no fun, is it?

So – I’m not trying to be negative about this or anything. Although it might not sound that way, I can imagine certain things that might be possible to do in screencasts, even though I suspect the overhead would be big. But what are your thoughts? What would you expect to see in a screencast that’s part of a documentation for the process of writing a whole application?

We’ve heard it more than once over time: Our components and libraries are great, but it’s often difficult to understand how they can be used together in real-world applications. Our demos do a good job of showing off the various features of the products, but often they don’t solve the problems that our customers are confronted with in their day to day work.

The Developer Express .NET Megademo is an effort to solve this problem. It will be an application, or most probably a set of applications, that implements real-world requirements using Developer Express .NET components and libraries. The process of creating this demo will be documented on this blog. I would like everybody to participate in the effort by submitting feedback on the blog, and by discussing functional and implementation decisions as we go along.

What will the demo do?

At this point I’m still open to suggestions, and I expect there will always be room for further ideas and extensions. One of the targets of the demo, in the long term, is to cover a big part of the functionality provided by our products, so this will define a number of the features that will be implemented. But at the same time it’s important for the demo’s functionality to be familiar to as many people as possible.

My current plan is to create an application for a small factory. This should provide for a wide range of functionality, as the factory needs to buy and sell parts and goods to and from business partners and customers, manage employees, handle financial information, run a web site for online shopping, do data analysis and so forth. While not everybody may be an expert in this subject matter, I expect it’s sufficiently familiar to most of you. Please feel free to comment on this plan – maybe there’s another even better idea out there.

How am I going to integrate all the products and all the functionality?

Well, I’m afraid I will probably end up not integrating all the products and all the functionality – it is just impossible. An example: It would be great to use XPO as the data storage platform for the application, and I definitely plan on doing that. But on the other hand, there are certain specific problems and approaches involved when using our other products (like the UI components) with ADO.NET directly, and by making a decision for XPO the demo will not show some implementation details that would be relevant if it wasn’t using XPO. No way around that, I’m afraid… if you find that at some point functionality is implemented in a way that works around a problem you’re having, please comment and mention this. If possible, it will be a good idea to explain such specifics at the point.

As another example, I’m planning to implement the application’s functionality based on our eXpressApp Framework as well as stand-alone. I expect that in many cases things are going to be a lot easier to do with XAF, but then there will probably be cases when they’re not – in these latter cases, the demo will have to go in two directions, which is one of the reasons why I originally mentioned that we’ll be talking about a set of applications.

Why don’t we use an existing application for the demo?

When we revamped our web site recently, the whole Support Center functionality was implemented using XPO and XAF, and there were some requests in the newsgroups for this “application”. It is well possible that we’ll release the Support Center as a demo in the future, but I decided to go a different way with the .NET Megademo. There are two major reasons for this:

1. The .NET Megademo can be a lot more useful if it shows how real-world applications can be created without the use of XAF. This is not because I don’t like XAF – I think it’s great. But I’m trying to create some educational benefit here by showing how things can be done, and the way to achieve this is not by saying “look, you take this black box and boom, everything works.” Of course it will be a great showcase for XAF to show how much easier things are based on that product, but I’m sure most of you see things like I do: it’s a much easier decision to go use a black box if I know exactly what goes on inside.
2. While the .NET Megademo wants to be a project that could be implemented in a very similar way for a real customer, it’s not actually in use with any real customers. That allows me a certain degree of freedom in functional decisions, and when planning extensions to demonstrate specific areas of functionality in our products. In the end, it’s first and foremost a demo of functionality in our products, and of approaches to using that functionality and integrating it. It will be implemented in a way that makes it relevant to the real world, which is good, but I’ll feel free to leave out certain real-world functionality if it serves no demonstrational purpose.

Who can use the demo?

Everybody, at least that’s what I hope. As it will eventually use all of our .NET products, a full DXperience installation will be required, as well as XAF for that part of things. But I assume it will be possible to use trial versions in case some components are not licensed by a customer.

In addition to the source code of the demo, I plan to make binary versions available, so it should be easy to download a version of the demo and play with it.

What’s the platform going to be?

I will use .NET 2, Visual Studio 2005 and C#.

How long will it take?

Long, if not forever. I see this as an ongoing effort, and while it is possible that we’ll come to the point where a certain amount of functional coverage has been reached, changes and extensions in our products will forever provide room for changes and extensions to the demo.

What’s next?

First, I hope for some comments, feedback and discussion. At some point in the next few days, I will then start the project by creating a first concept “paper”, in the form of a list of functionality to be included in a version 1.0. I will try to keep the overhead low in the area of project planning and management, so when the target is set, I’ll start working on the implementation. I will progress feature by feature, and I hope to be able to publish an interim version and a corresponding blog post for each feature that’s completed.