A day in the life of...

An onion has layers... ...Shrek In the beginning When I first started writing applications they would typically be a single program editing a single datasource. As time went on this changed because people wanted to share data, so client/server applications appeared. It didn't stop there though, N-Tier applications became much more common. Applications were typically split up like this: RDBMS--DAL--Business classes--UI Due to the fact that I use ECO for my business layer , and that ECO has the DAL built in, the illustration for me would look something like: RDBMS--Business classes (ECO)--UI Thinking of business problems as classes instead of tables really helps to simplify your design, so I have been very happy writing applications this way for some time now. The application layer In December 2005 I was tasked with the job of writing quite a complicated Compact Framework application. Although this application was going to be complicated it needed to be very simple to use, as the

This is just a copy/paste of a reply I made in a newsgroup, but I think it is quite informative so here it is.... KEY Square brackets denote a class [Person] Rounded brackets denote a role (Pets) Let's say you have a Car class and a Garage class, an individual car is regularly serviced at a specific garage so you have the following association [Garage] (Garage) 1----0..* (ServicableCars) [Car] Car.allInstances->select(Garage.Code = '1234') The above OCL will fail because "Garage" is a class so the parser is expecting stuff like "allInstances". So you might think this should work Car.allInstances->select(self.Garage.Code = '1234') but it doesn't because "self" refers to the root object and not the object at the parsed node where it is specified. This is what aliases are for: {aliasname} + {pipe} Car.allInstances->select(currentCar | currentCar.Garage.Code = '1234') This was possible in Bold too (native wind

What is a Customer? If you are some kind of business service provider then it will be a Company, if you are a window cleaner then it will be a Person, but if you are a travel agent it could be either. What about a Supplier? You could argue the same as for a Customer, but you could also argue that a Company/Person could be both a Supplier and a Customer. This is where Roles come in. A Supplier isn't something you are, it is something you do, you supply something; just as a Customer consumes something. I find that it is much better to enable "Things" to perform more than one action, it is rare that life is simple enough for everyone to perform only a single role in life. The typical solution to this is the Party/Role pattern. A good point to make here is that this is a pattern, not a set of classes intend for inheriting from! This means that when you have a Company (alias "Party") you should create a CompanyRole class and associate them, descending Custome

I spent the day (March 2005) training someone how ECO works. Between 9:30 and 12:30 we went through the basics, how to create a model in a package (and why). We then covered the different component types, whilst making a simple client/server app. Between 13:45 and 17:00 we went on to Create a server application Convert the client to connect to the server instead of directly to the DB Make the client synchronise with the changes from the server Create a web service which connected to the server for persistence Create a website which connected to the server for persistence That's a lot of work to get done in 3.5 hours at the best of times, but when you are also explaining why everything is done the way it is then this is surely a reflection of just how quick it is to develop applications using ECO. Everything we did was adhoc. I had no idea what the trainee wanted to cover before he arrived so everything was written from scratch. I'm quite frankly surprised that we managed to

This question has been asked so many times. Jesper (one of the developers) recently explained it like this... ECO, Enterprise Core Objects, is a model driven framework. In essence, it allows you to specify your application using a UML class model. This model is then transformed to source code, decorated with enough information to re-create the model information at run time. The framework uses the model information (as contained in and re-created from the source code) to drive persistence, presentation, maintain the technical integrity of the business objects, manage bi-directional relations, derived associations and attributes, maintain constraints, offer services like undo/redo, object versioning and quite a bit more. The value added proposition for you is that you can design your application on a 'higher level', without worrying about implementation details. Use the model not only for communication of ideas, but also as a part of your application. You can code your business

The focus of this post will be "Event derived columns". Jan Nordén (Borland) pointed me in the direction of these things recently when I asked him how to solve a GUI problem I had. When I used Bold for Delphi there was this really nice GUI component called a BoldSelectionListBox. This component would let me show a list of items with a CheckBox next to each row, ticking / unticking a box would add / remove an association between the object selected and some other object of my choice. Using this BoldSelectionListBox I would be able to specify a User (for example) as the context and then have a list of all Groups in a kind of CheckListBox. Ticks would appear in all CheckBoxes where the User is belongs to the group listed, and no tick where they are not part of the group. The extra clever part of course is that by ticking a CheckBox Bold would create the link object required to tie the User to the Group, and add it to User.Groups (and of course Group.Users). Seeing that ECO