CSLA Framework and Web Apps?

CSLA Framework and Web Apps?

Old forum URL: forums.lhotka.net/forums/t/1807.aspx


RBrown posted on Tuesday, November 21, 2006

Newbie question:   I'm only 20% of the way through "the book" but am a little curious (nervous) on the use of the framework for web applications.   I see a ton of references to Windows forms, and how the framework works very well with win forms in regards to databinding, error management, undo etc.  I don't see a lot of references to ASP.NET or web apps, not yet anyway.  I know that Chapter 10 will deal with the Web Forms UI implementation, so I know it is addressed, but I'm jus concerned that the complexity of the framework is more geared towads WinForm apps and to use it in a Web App would be overkill.  Am I off base with this concern?

I am VERY impressed with the depth of the framework, but I'm just concerned that it's overkill if you are primarily building web applications.  For instance, there appears to be a lot of code  in the framework (and pages in the book) dealing with the Undo feature, yet it's quickly dismissed in the web environment where the object state mgmt requirements aren't as big of a concern.  Also, the use of Binary format rather than SOAP in the serialization process seems to discount that the objects might need to pass though firewalls.  This generally isn't a concern for local Winform apps (unless distributed) but certainly is for Web apps.    

Please forgive the CSLA ignorance as I'm just trying to come up to speed on this.  I would LOVE to use the framework as the idea of adopting a business object methodology that has the user community support that CSLA has (and Rockford!) is extremely appealing to me.  Beats the heck out of rolling my own methodolgy and then having to account for all the new .Net framework changes all by myself.

I just want to make sure that others find the framework as wonderful for creating Web apps as they do for Windows apps.  I'm sure it is...just want to increase my comfort level :)

Thanks for any/all feedback.

ajj3085 replied on Tuesday, November 21, 2006

Hi,

The undo code is there, yes, but it doesn't add any overhead if you don't use it. 

Also, the binary formatter can be opened to pass through the firewall from just the webserver on the DMZ.  This should present a minimal security risk, at least its smaller than opening your DB directly to the web server and having db passwords coded into your configuration file.    If its a real problem, you can use the WebServices data portal proxy, which will transfer the BO using SOAP.  You have a lot of flexibility on how to move a BO from one machine to another with Csla.

Its true you may have to design your BOs differently, but this is more to account for the fact that you may not have any good state storage on the webserver, but you will still gain many benefits, such as a single point where all your business rulse are kept, good OO design, databinding support, etc.

Other's have used the framework with great success to build web applications, i don't think you have anything to worry about.

HTH
Andy

RBrown replied on Tuesday, November 21, 2006

Thanks for the rapid reply Andy.   I'll will read on and see :)

In the interest of object flexibility, I can understand the use of the BinaryFormatter...especially if you don't need the interoperability that XML would provide to non-.Net systems.  As Rockford suggests, the BinaryFormatter is far more encompassing on the allowable types that can be serialized and hence a better choice for mobile objects.

Not sure on the port issue though, can't always count on the ability to open a port.  As you suggested though, I could always turn to a Web Service interface for exposing data that needed to traverse the firewall.

I'm curious about how CSLA will be used for sending BOs to the brower client for consumption in the emerging ASP.NET AJAX methodolgy.  Right now the server AJAX technology is big with the Update Panel usage, but soon all the client side JavaScript libraries will be in full swing and the idea of sending a true data hydrated BO to the client (JSON) is very appealing for the potential UI enhancements.  I guess this is better left for another post, but goes along with the original question of transferring BOs outside the firewall.   

Thanks again Andy

Randy

RockfordLhotka replied on Tuesday, November 21, 2006

RBrown:

I'm curious about how CSLA will be used for sending BOs to the brower client for consumption in the emerging ASP.NET AJAX methodolgy.  Right now the server AJAX technology is big with the Update Panel usage, but soon all the client side JavaScript libraries will be in full swing and the idea of sending a true data hydrated BO to the client (JSON) is very appealing for the potential UI enhancements.  I guess this is better left for another post, but goes along with the original question of transferring BOs outside the firewall.   

That's a whole other thing in my view. The code in the browser can never be trusted - not from a security or semantic perspective. Thus the code in the browser should be treated as a totally seperate application from any of your server-side code. As a result, the idea of passing serialized objects between your browser-based app and your server-based app is a bad idea.

Instead, I suggest you use service-oriented concepts and pass messages between the two applications. In your server app, you may use the content of those messages to manipulate or interact with your business objects - but those business objects would never be directly exposed to an untrusted consumer.

That model fits very nicely with AJAX .NET, because that technology uses web services as a transport and is designed to be passing messages from the client app to the server app. My only compaint with it is not technical - it is that too many people view the browser and server code as being tiers in a single application, which is absolutely not the case...

JoeFallon1 replied on Tuesday, November 21, 2006

FWIW,

I have used CSLA in a very large Web app for about 3 years now. It is a great framework to build BOs which can be re-used in WinForms apps if necessary. I have had a lot of success doing that too. I have a handful of small apps that process data on a scheduled basis and they are Winforms apps that use the same BOs. Makes things very simple. I don't use Undo in the Web apps. I also do not re-design my BOs to be "Web only"  as some people have suggested. I use normal Root/ECC/Child BOs and they are fine. Ditto for ROC and ReadOnly BOs.

Binding is straightforward too. You can set the datasource for a grid to a collection and it works fine.

I highly recommend CSLA for web apps too.

Joe

 

Copyright (c) Marimer LLC