search

MarimerLLC / cslaforum

Discussion forum for CSLA .NET
https://cslanet.com
Other
31 stars 6 forks source link

CSLA Support for Web Applications #326

Open cslacoder2017 opened 7 years ago

cslacoder2017 commented 7 years ago

We have seen WPF applications working with CSLA with object graph maintained both at client(WPF) and server side(WCF)

i would like to know how much support we have with CSLA on web applications (stateless applications) where there is no object graph maintained on the client side(javascript running on browser) .

What is the typical architecture for a javascript app(eg Extjs/AngularJs/other JS) with stateless webapis on the server side ?

Are there any constraints/limitations on using CSLA with web applications ?

bradtwurst commented 7 years ago

My personal opinion as I am also looking at dealing with creating web API's based upon a CSLA system.

Conceptually, I would approach this architecture with a perspective of Queries and Commands messages and separating the 'public' interface from the 'internal' implementation.

Queries: a message that requests data/information from the 'server' - I would not use objects based upon CSLA bases, but instead simple data structures to communicate between host and client.

Commands: a message that requests that the 'server' do something - Again, I would not used CSLA based objects, but again simple data structures for communication purposes.

On the server side, for either queries or commands, you would map the data structures to/from CSLA objects. The advantage of this is that your 'API' is not tied directly to the structure of your business objects and there can be a decoupling based upon actual purpose.

constraints/limitations/drawbacks:

Any rules logic in the CSLA logic is not available on the client side, thus you may need to duplicate the rule logic for UI purposes.

Data structures would need to be created to support the various queries/commands and the associated data mapping logic. This may result in a lot of boilerplate code if you are doing a straight one-to-one mapping from the CSLA objects.

I would suggest that each individual query/command be evaluated in its specific context to determine the information that is really needed to drive the business process forward.

I would expect that many query/command messages will be very light, simple, and flat.

If not, then this may indicate that the actual purpose of the query/command may not yet been truly discovered.

This strategy is also echoed in the blog post (especially the last few paragraphs) found at http://www.lhotka.net/weblog/SimpleServiceImplementationWithCSLANET.aspx

As a side note, these stateless web concepts are not CSLA specific, but instead is a approach to creating web-based (thin client) applications in general

Hope that helps, James

rockfordlhotka commented 7 years ago

James's view fits with mine for the most part.

CSLA supports the creation of business domain objects that match the requirements of each user scenario (sometimes called a use case). In the web server world, due to the stateless nature of that environment, there are technical limitations imposed that pretty much require your user scenarios to be implemented using stateless object models.

And that's OK, though it means you probably can't reuse those same domain objects in a stateful app scenario (e.g. any smart client scenario such as WPF, Xamarin, etc.).