Yes, if you change the namespace, you have to remember to modify it within both the main code file and the designer file.

Ah, I changed the namespace, which required messing with all the designer files.

Moving a class from one project to another is acutally quite easy.  As long as the namespace doesn't change, you can move a class from one assembly to another without any problems (as long as the new target assembly is referenced, of course ).  So, just make sure that the namespaces are the same and your project is referenced and then drag the item from one project to another within the Solution Explorer.  If you just drag it, it will copy it, but if you shift-drag it, you will move it to its new location.

The only thing you're going to lose is the configuration for your business objects.  However, if you move all of your business objects into one project, then you can simply reconfigure the project within the BOMapper and select the BOMapper project that contains the configurations.  If you split your BOs into several assemblies, then you're going to lose some of the BO configurations.

I did it this way I had about 80 BOs when I realized that I needed to have a library.



It wasn't fun, but it wasn't horrible (I went from 1 project to 6, so I had other issues to deal with besides the BOs). You'll hate yourself the longer you put it off.



The process is to create a new BO project, move the BOs into it, be sure to setup your namespaces.



Add a reference to the BO project in projects that use them (obviously).



Then fix the reference to the BOs, usually in designer files for forms. In code, you'd just add an Imports statement (using in C#). This isn't too bad, because you'll get a bunch of error messages, so you'll know where they are.

How tough is it to split the BO's out into their own project if you've already gone down the "wrong" path?



I don't have a whole lot of BO's now so this might be a good time to re-factor this....

Having just attended the training class and now referring to the training materials, I'd have to say I agree: the training material is a good reminder but doesn't provide all the details that come with the lecture and especially the sample projects (built by Trent or Ben while giving the training...again excellent for those in the training to remind us of how to do something or of a concept).







Again, I would agree. The class provided in depth coverage into SF but even more importantly it provide that training in the context of building real applications (they use there medical software as examples of techniques in many cases) and much of that is .NET related, not just SF specific. A few of us suggested to SF that they should consider offering application development classes, I.e. classes that focus on the actual details of building an application, in real life. Alas, for now they probably don't have the band width to do this.

The training material alone may only confuse the issue more since it comes without explanation.  I think that it would really help you guys tremendously if you could attend the next training class.  If you started planning now then I think you would have plenty of time....but even though time has passed and you are well into your project, I think coming to the training class would give you guys a lot more depth and understanding to the framework and even .NET in general as we cover a number of .NET elements within the class as well.

Thanks Trent. I was just re-reading this today because I was going to try my hand at setting up a test BOL.



P.S. It would be super cool if I could get my hands on the syllabus or a video version of the training for a reduced price. ;-)

First off, the BO library is just a class library (DLL) that already has the StrataFrame references.  That is basically it.  Now, as for your BOs, you should definitely be housing all of your BOs in a BO library rather than in your primary application EXE.  In fact, in our training classes we cover how to setup your application environment and how your BOs should be split apart, namespaces, etc.  This too much to cover within the forum, but all in all you should definitely create a BO library and place your BOs within that assembly.

I noticed that there is a business object library template under the StrataFrame projects. I was wondering if this template was talked about at all in your documentation and where I would find that. If not could you summarize the template for me?



Also, my boss and i were talking the other day and it seems like a business object library would be beneficial to us... i'm just not sure how to approach creating/implementing one. Does any body have any advice/links?



Thanks.