Questions from Chris Russi

Topics: Developer Forum, User Forum
Sep 5, 2007 at 2:12 AM

I am curious to know, since you work at Magenic, do you use CSLA in your day-to-day projects?
    • We use CSLA quite a bit at Magenic, I have personally worked on several projects where we used CSLA and a few that didn't. Of course it helps to have Rocky personally available to answer CSLA questions as you're learning it :)

I know you mentioned in your blog that you were prevented from using CSLA on godaddy because of the medium trust issue. I have also run into that on a similar website for a web project I did once.
    • Actually I had done some work on a code generator at work that generates CSLA business objects and was about to begin working on a website for my own interests when I came across this limitation. It was a combination of needing a different solution and some of my own thoughts of how to do a better job with code generation that really brought me to create NBusiness. I have had lots of interesting conversations with some coworkers, including Rocky, about creating a traditional style DSL and finally decided to go for it.

Is the framework you came up with similar to CSLA?
    • The default framework that comes with NBusiness is similar to CSLA in some ways but not so much in other ways. It turns out that the Medium Trust issue is a tough one to work around for some of the features of CSLA. For example, there is no Dataportal. This is a direct to database access layer. I suppose it would probably be possible to work in your own Dataportal type deal... but it's certainly not part of the default framework for now. Addtionally there is no N-level undo... there could be maybe but it's a little harder to do in medium trust.
    • Also the framework is just one of the several components needed to get this whole thing to work so it doesn't have nearly the level of focus, maturity or number of features that CSLA has. Additionally, I could be a bit naieve about this point, but I don't think that there is formal support for persisting relationship objects in the business base classes, at least to the extent that I would like. So in that way I think it's maybe a little better, though you could certainly get nearly the exact same results with more work in your templates. But in general I would say the "feel" of working with the generated objects is very similar, for example you might create the following code to consume your NBusiness objects:
    Customer c = Customer.CreateNew(); //Factory method for creating a new business object
    c.FirstName = "Justin";
    c.LastName = "Chase";
    Assert.AreEqual(0, c.BrokenRules.Count);

You've mentioned in your blogs that it shouldn't be that hard to gen CSLA compliant objects from NBusiness; have you actually done this?
    • No I haven't done this yet but it's a goal of mine. I have however done the templates for generating classes for the default framework and it would simply be a matter of generating code that targeted a different framework. I will say however, that in reality it probably wouldn't be "easy". Rather, it would be easy to do it but it would not be very easy to do it well. As we all know your business objects can get quite complicated and solving the problem in a generic way is even harder, however NBusiness was specifically designed with this in mind and therefore is absolutely possible.

What are your thoughts about using N# instead of other ways to store metadata ( i.e. XML) now that you've had time to work with it?
    • First off, you probably mean E# rather than N#.
    • Well I'm obviously biased but if you're willing to overlook that then I think it's absolutely great! I built an entire backend for my blog website in about 10 minutes, no joke, and hooking it up to the front end was very easy as well. This was an extremely simple example but just goes to show you useful it can be for small, medium trust websites at the very least. The jury is definitely still out though! In a lot of ways this project is really still just a hypothesis about what is the best way to express a domain specific language, for entities or anything else for that matter. The theory behind NBusiness is simply that it's most intuitive for coders to think and develop in code than in any other way. For example, I like the class designer that comes with VS 2005 but only for looking at relationships between classes that I have already created, I would never use it to actually author code. The why's behind this are probably beyond the scope of this post but I think most coders probably feel the same way.

How hard was it to develop N#?
    • VERY. I've been working on it for over a year now (I think) and there is still much to be done!
    • To elaborate more I'll tell you that there are several components to NBusiness and each one was pretty hard. To give you an idea the various components there is the Compiler/Parser, the Templates, the business object framework, some web controls, MSBuild classes, Example website, visual studio integration and an installer. Each one had it's challenges but without a doubt the visual studio integration was the hardest. Quite possibly the hardest thing I've ever done and that was with virtually copying the IronPython example that came with the SDK. I would absolutely not reccomend ever creating a visual studio integration project unless you're either well financed or extremely sadistic (or you use the DSL tools).
    • Integrating with visual studio forced me to rewrite the entire parser I had created prior to that point. It was necessary in order to get the information I needed to enable intellisense. It's hard to forsee those types of things when you make a compiler for the first time, that's for sure. I should probably also mention that I'm no compiler expert, I mean it works but it's really the only one I've ever worked on. I've never even taken a compiler course in college so as far as I know it could be an extremely primitive an embarrassing compiler (ignorance is bliss)!

Thanks for making all the source available ... it's going to be fun checking it all out :-)
    • You're welcome!