Is It Possible with CSLA?

SimpleCSLA posted on Wednesday, May 23, 2007

I just received my Expert VB 2005 Business Objects book yesterday.  After downloading CSLA Project Tracker and continuously getting a DataPortal.Fetch error, then reading dozens of such problems on this web site, I (we) have literally wasted 2 full days trying to get the program running. 

So here's my question - is this framework worth the hassle?  I'm being 100% serious - do you guys really read the entire book before trying to install the sample web or did it just work when you installed it?  We've got 15 programmers here and three of us are trying to figure out why we keep getting DataPortal.Fetch errors.  We've installed the EnterpriseServicesHostvb.dll, but it seems that the dozens of errors people have received have numerous possible solutions.

The other 12 programmers are just snickering saying "We told you CSLA was too complicated?", but I can't imagine it is.  There has too be something dumb I'm missing.  I've gone through Chapter 12, but everything seems fine.

If its of any help I think the section in the web.config <add key="CslaAuthentication" value="CSLA"/>, has something to do with the problem.  It keeps returning the IDENTITY.IsAuthorized=False,  but I can't figure out why.  Changing the value to "Windows" only gives me an error on the line "Return svc.Fetch(objectType, criteria, context)" in EnterpriseServicesProxy.vb.

Sorry for my EXTREME frustration.

Michael Hildner replied on Wednesday, May 23, 2007

Did you check out the InnerException of your DataPortalException? That will give you some details.

Brian Criswell replied on Wednesday, May 23, 2007

First, hands down CSLA is worth the hassle.  End of story.

Second, there are a few things you should be aware of:

• As with any framework, there is a learning curve.  CSLA encompasses app/server, authentication, authorization, validation and more, so the curve is a bit steep, but when you learn the stuff (a few weeks of spare time for me), you know pretty much all there is.
• Because of the way the DataPortal works, you need to create your object graphs so that there is a single root object in an fetch/insert/update scenario, as that object becomes the entrypoint into the DataPortal and all of the child objects hang off of that single root object.
• The previous item means that you must make objects that fit your use cases not your data.  A classic example would be that your application allows an administrator to select users and edit them.  Many who start with CSLA make the mistake of creating a list of users (UserList of User) and allow the administrator to select one of the User objects and edit it.  But everything works much better if you have a UserInfoList of UserInfo objects to select the a user.  UserInfo has just enough information to select a User from a list (Id and Name).  There would then be a User object that handled the edit user use case.

Third, a few of the benefits:

• Because CSLA handles, authentication, authorization, etc., the business object programmer is able to focus on just the behaviour that makes that object unique.  There are simple and specific entrypoints into the plumming code that CSLA provides.
• Even though you find yourself making more objects, this does not require too much extra initial time and means your are making more maintainable code.  Object Thinking by Dave West gives some good insight into breaking objects down by behaviour instead of by data.  This does mean a shift in thinking about OOP for most people, but it does mean that they usually end up being better programmers.  On the other hand, some people refuse to alter their thinking and then find that parts of CSLA just will not work for them.
  
• Your objects are very usable by other developers (such as UI developers).  I have had people say some of my objects look over-engineered because of the validation rules and entrypoints into the CSLA base classes, but I am then able to work with the objects in ways that the other programmers are only able to dream of (app/server, instant sorting and filtering, UIs that react to the object's status, and more).
• A vibrant user community that has a very low signal to noise ratio.  People who were newbies a few months ago are already helping the new newbies, and Rocky himself answers a lot of people's questions and gives practical advice.
  

Your specific problem could be many things from a missing option in a config file to missing permissions in the database.  The exception thrown has a BusinessException property on it that will tell you what exception occured within the DataPortal.  When you get that exception, if you cannot figure it out yourself, post it on the boards here and someone should be able to quickly help you out.

Also, if you have any other questions about the framework, ask them and we will answer.

Also, what version of the framework are you using?

xal replied on Wednesday, May 23, 2007

So, I gather you're trying to run the Project tracker. I see that you're having trouble with the enterprise services host. Do you really intend to use Enterprise Services?
If the answer is no, then take a look at the app.config and comment out the enterprise services part.
Enterprise services can be a pain to configure, but if you just want to get familiarized with the framework, you don't really need enterprise services or remoting.
In that case, comment out anything in the web config that defines a dataportal proxy and a dataportal url. Just having the connection strings in the app config will have csla use a simple portal that connects directly to the db.

Once you're comfortable with csla you can test other setups like remoting, which is the most common for client server setups.

I hope that helps.

Andrés


PS: Yes, it's is really worth it. (but I'm biased) :D
PPS: Also, once you're more comfortable with csla, you can take a look at this.

xal replied on Wednesday, May 23, 2007

Also, here's a guide to setting up the project tracker:
http://www.lhotka.net/files/csla20/BuildCsla.pdf

Andrés

SimpleCSLA replied on Thursday, May 24, 2007

The error I keep receiving is:

DataPortal.Fetch failed (System.NullReferenceException: Object reference not set to an instance of an object.at ProjectTracker.Library.Database.get_SecurityConnection() in
C:\CSLA_214\csla20vb\ProjectTracker20vb\ProjectTracker.Library\Database.vb:line 13 at ProjectTracker.Library.Security.PTIdentity.DataPortal_Fetch(Criteria criteria) in
C:\CSLA_214\csla20vb\ProjectTracker20vb\ProjectTracker.Library\Security\PTIdentity.vb:line 110)

I put a break point on Line 13 in the Database.vb class, but it never stops. 

I've read through Chapter 4 where Lhotka recommends using the LocalProxy, but I don't know on his Project Tracker program where to set it to use LocalProxy (maybe it already is).

ajj3085 replied on Thursday, May 24, 2007

Are you trying the WinForms application or the asp.net one?  If its WinForms, check the App.Config file.  Otherwise, check the Web.config file.

there are a few things to look for in those files.  One would be anything DataPortal settings Andres (Xal) has already discussed.  The other is the database connection strings.  I THINK that Rocky has things setup for Sql Server Express, where you specify a file path to the .mdb file and SSE will create a User Instance.  Basicaly an instance that only exists for the user while the app is running.

If you're not on Sql Express, you should 1) Attach the mdb file to your running Sql Server instance and 2) change the connection strings appropriately.

Note that there are TWO databases; a Security database and a PTracker database.  You'll need to attach and change the connection strings for BOTH to get the sample working.

HTH
Andy

dlambert replied on Thursday, May 24, 2007

Any time you build an application from scratch, it's easier to start with "Hello, world", and build only what you need when you need it.  That will last until the application reaches a size where the complexity you've built starts to become your own worst enemy. 

At that point, if you examine what you've built, you'll begin to realize that the stuff you've constructed covers a portion of the functionality in a framework like CSLA, only it doesn't work quite right.  I can say this with some confidence because I've found myself in this position a couple of times. 

The real value of this kind of framework comes over the course of a project when you'd normally reach inflection points where things break for no apparent reason and massive hunks of the system must then be refactored.  That's less likely in a framework-built application because the structure of the framework helps channel development in "healthy" directions.

You can also see value in a framework like this when it's used across multiple applications in an enterprise becuase the learning curve for a new developer is compressed.  Learn one framework, and you're well on your way to understanding multiple systems.  Based on your original post, I think this could be the case for you.

Just a word of caution:  If you're facing a room filled with nay-sayers, you could be in for a tough battle.  That sort of mob mentality has a way of latching onto any excuse, real or imagined, in order to get its way.  Keep an  eye on the political aspects of this evaluation in addition to the factual aspects.

SimpleCSLA replied on Thursday, May 24, 2007

Thanks for the help.  In another thread Rocky gave me some tips and I turned off EnterpriseServicesVB.dll, and ran the data locally via my own SQL 2005 dbase.

I am now in a position to write some basic code and argue for using CSLA (assuming I like it, which I probably will).  Later I can attempt to get remoting to work, but for now all is well.

For those who care, the solution was to comment out the EnterpriseServices call in web.config.  Once that is gone, Database.vb looks at the connection string.  Once the connection string is right, it works.  I couldn't get this to work with SQLExpress, but 2005 caused no issues.

Thanks again.  

DansDreams replied on Thursday, May 24, 2007

All frameworks are complicated inside by definition.   The only way they provide value is hiding the complication. 

That's true of the .NET framework as well, of course.  Who wants to go back to manipulating strings the C++ way?!  You could argue it was decidedly "simpler", but it was way more difficult overall in the long run.

I've found that a new developer can be productive working on my enterprise application with almost zero understanding of CSLA.  In fact, they can use copy and search/replace and create a new fully-functional robust business object in short order.

Precisely the point of the framework in the first place, IMO.  It's why there is an Enterprise Library from Microsoft.

So, yes, you could do that too, starting with the ProjectTracker sample application.  No, you don't really have to read the book to use CSLA.  But somebody in your organization with the architect role/responsibility should.  Many people that start pushing CSLA end up wanting to change or add behavior, and you do need some level of understanding for that, of course.