It’s been a busy time around here but I finally found time to update the code base for this tool.
Thanks for the great feedback and comments about the tool. Please keep the suggestions coming and I will try to work on as much as I can when I have time.
I recently started teaching again and just completed my Microsoft Certified Trainer program as well as attained the Microsoft Certified Professional Developer in Windows .NET 3.5 Applications.
But in the not so busy time here is the list of issues that we have corrected:
- Self referencing classes now produce correct code
- Ability to add custom attributes. Use the the CustomAttributes field.
- Ability to add custom rule messages
- Target and source properties can now be named rather than the default object name
- Default property of class is now definable
- Aggregated attribute has been included
- Creatable and Navigational properties are defaulting correctly
- Base class is no longer blank
As always, it’s available on codeplex at http://xafdsl.codeplex.com.
Enjoy!
OK. Now that I have time to look at it, I also added an installer (MSI format) for everyone. You can download the installer and not have to worry about the source code anymore. This will allow you to more quickly get up and running with it and use it out of the box.
You can download the latest source code and installer from http://xafdsl.codeplex.com.
Thanks
OK. So I finally found some time in my schedule to back to this project. I found and updated the issues with the code generation when I changed out all the namespace. Feel free to download the next version and let me know what you think.
Now when you create your Object Model and save it, the code files are generated as in the demo. Let me know if it still doesn’t work for you and I will see what I can do.
Thanks again.
OK. I finally had a little bit of time to get the namespaces changed and get this project published to CodePlex. It is still in a rough form and needs some more changes to make it fully operational, but it has enough for others to see it.
Let me know what you think. Please enter features so we can get them prioritized and working. I have some ideas of where I would like tool to go but want to let everyone see it as well.
You can find the source at http://xafdsl.codeplex.com.
Thanks
I got a couple of feedback items about seeing the XAF Code Generator in action so I decided to post a quick video of it.
There is not any audio, but this video shows you how we create a new DevExpress project. It then shows the DSL tool interface and how it generates the code files on save. It will generate two partial classes. One for your concrete implementations and one for your code generated components (similar to a form designer). And finally I showed how you can make a field required and the attribute tag gets generated for you based upon the XAF attributes.
Click here for the video. Let me know what you think.
Thanks
I have not been very good at keeping up with this blog, but the theme is the same. I started this blog with a simple theme of being able to sit down with my end users and quickly and easily diagram their requirements to produce a prototype as quickly as possible.
I started on a project I was calling Domain Builder as well as a few other side projects. But not until the last project at work did I think this had much traction any more.
We have began using a framework from DevExpress call the Application Framework (XAF). This is a complete windows and web UI framework wrapped around their Persistent Object (XPO) framework. If you have not had a chance to explore it, I suggest you do. If you are familiar with NHibernate, this has a similar ORM component to it, but the XAF makes the UI generation just as easy.
The major modification we made to it was to utilize Domain Specific Languages (DSL) to include a designer interface similar to the class diagram tool within Visual Studio. This allows us to quickly sit with the end users to model their application. Once we hit the save button, the business model classes are generated based upon the XPO/XAF attributes. We can then run the application for the first time and within a matter of minutes, have a working prototype.
From there, we use the power of XAF to complete the UI design. This framework has proven to be very flexible and powerful at the same time.
If you have any questions or comments, please feel free to send them my way.
It is with great heartache that I updated the progress of Domain Builder. It seems as though the Domain Builder project might be meeting an untimely death. While I still have great pride and joy in the progress made thus far, I have been working with the new MVC Toolkit bits from Microsoft and the areas that they are moving forward on. These tools are already tackling several of the areas that I was looking into. Instead of being responsible for a framework, I can again focus on the business problems at hand.
These technologies rock!!! The DynamicData website project absolutely makes quick work of making down and dirty CRUD (Create Read Update Delete) operations out of the database. This is great from the perspective that it creates a quick site but allows you to customize it to your liking. Just like what I wanted to do, so why waste my time trying. Let's learn new Microsoft tools.
Next, I did a quick look into the MVC (Model View Controller) and discovered that it is quite similar to the MonoRail project at Castle Project. While I have implemented the MonoRail on one application, the MVC pattern makes sense and was an easy transition. It doesn't hurt that my experience has primarily been in Microsoft technologies. The MVC pattern makes a whole lot of sense if you think of it like this: The view is nothing more than a dumb-terminal (just displays and accepts information), the controller responds to the user interactions and directs traffic (he know how to get things done) and the model does the work. The way this fits together, the model can then be anything you wish. It could be a service oriented approach, CSLA project or other entity frameworks. Again, the controller does not DO the work, but knows who to contact to get the job done.
The other area that I still need to research it the Entity Framework. While the concept here is very exciting, how does this compare to the rich business logic within CSLA? Still trying to figure this one out.
I'm heading back to the laptop for more research time, but this stuff is extremely exciting!!! Keep going Microsoft.
I have been working on the domain builder but still reading articles and blogs. While I still love the idea and the concepts, the MVC presentations are really slick. I think that I am going to change direction just slightly and focus on the MVC pattern from Microsoft.
I still plan on having CSLA and NHibernate talking together. I just read another article on Ayende's site about having NHibernate using LINQ. I will explore this further as well, but right now my focus is getting the MVC pattern talking to CSLA. This will provide a quick way of seeing and consuming the business objects while still providing a rich business layer. The CSLA layer will then talk to NHibernate through LINQ and call the database as configured.
This change will then require the project to be framework 3.5 rather than 2.0, but this is a sacrifice that I am willing to look into. Until I write again, happy coding.
I know it's been awhile since I last posted, but let's blame it on the holidays.
Anyway, what I wanted to post today are screen shots of the latest working code. First I'll start with what the domain builder interface looks like. It leverages the DSL (Domain Specific Language) interface as part of the Visual Studio SDK package. Click on the picture below for a closer look.
The model represented above has all entities sharing common attributes and thus inherit from the BaseEntity class. You will also notice that each entity has an italicized name under it. This represents the table name that the entity relates to. Remember that this diagram will code generate the business layer using CSLA, the data layer using NHibernate and then generates the model view/presenter layers for reusability. Note the solution explorer below. This shows the layers that are generated for you. Again, click on the image for a closer look.
The Domain Builder tool generates each of the layers above and adds the appropriate references that it needs. Here are the layers that are generated and my reasoning behind it.
| Layer | Description |
| Business | Utilized CSLA and handles the RootBusinessEntity for each entity in the model. |
| BusinessListLayer | Utilized CSLA and handles the RootListEntity for each of the entities in the model. |
| DataAccessLayer | Generates the property to column mapping using NHibernate. Each class uses ActiveRecord to handle the mapping in an easier format. |
| Interfaces | Generates an interface for each entity in the diagram so that the mapping between CSLA and NHibernate can be coded easier. Also, you should be coding for an interface and not for the actual implementation. |
| Presenter | Currently generates a list and detail presenter for each of the entities in the diagram. This still needs some attention, but I like where it is currently headed. |
| QueryLayer | This is one of the more interesting layers. This layer is generated based upon Ayende's Query Builder and create a "LINQ-like" interface for 2.0. This generates an API so that you can do something like the following:
List list = List.Retrieve(Where.Entity.Property.Eq(Value)); -> reads much easier and simplifies the code drastically. |
| View | Creates the views for the detail and list presenters. These are just interfaces that represent what the view should provide. |
There are more details to come, but I wanted to update whoever was still listening. Thanks.
To make things easier to track (and straight in my mind), I have created an open source project to share the domain builder. You can find the project at Domain Builder on Code Plex. This will everyone to follow along at home on the progress as well as provide feedback in the process.
Also, I thought would be important to share more of my detailed technical thoughts on the wiki as well. You can find this along with a list of open tasks and scenarios on the Code Plex website.
The other items within this post are the links to the inspiration for this project:
I have a simple goal. I want to be able to work with domain experts and quickly diagram the application area. This should be similar to the class diagram tool already built into Visual Studio.
Once the diagram is built and approved, the ability to code generate should be next. My idea here is to generate the Data Access Layer (DAL) by using NHibernate. This would allow the application to be database agnostic by generating dynamic SQL on the fly. The Business Persistence Layer (BPL) would be generated using CSLA (Composite Scalable Logical Architecture) by Rocky Lhotka. This allows the domain to take advantage of communication layer within CSLA which now utilizes Windows Communication Foundation (WCF). It also allows the N-Level undo and security layer utilizing the Principal and Identity objects built into Visual Studio. These layers working together provide for a rather robust and flexible middle tier(s) of the application.
My next idea for the domain model is to provide a swim lane diagram to document each of the interactions between the user and the application. These interactions would then be generated into Model View Presenters (MVP) so that the application could be wired to the domain. By using the Passive View, as described by Martin Fowler, the view becomes a dumb implementation that should handle just the specific UI logic and not any of the business logic. By doing this, the same presenter could be used between a Windows interface and Web interface, as well as a Mobile interface. All these working together would be able to deliver the same user experience regardless of the UI implementing the interaction.
And finally, the implementation model would be modeled using the Component diagram. This would allow the user to model how the application is implemented on the server(s), how the layers would communicate and where the database is located. This model would then code generate the configuration file(s) needed.
So, as you can see, this is a simple goal, but I plan on documenting the process as it progresses. If you have any comments or questions, feel free to send me a note.
