MVC and Csla

MVC and Csla

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


cliffordru posted on Thursday, June 12, 2008

In the following post by Rocky http://www.lhotka.net/weblog/RepostFromAnMSDNForumDiscussion.aspx he references how well Csla can work with the current Microsoft MVC framework.  Conceptually this makes sense and MVC looks very promising for some scenarios, but I am curious if anyone has done any work with MVC and Csla?  If so, any recommendations such as using MVC Contrib, how about the data binding support, active record (from a testability perspective) within the MVC framework, etc., and if you think the current MVC and Csla versions (practically speaking) would be ready for a production application (or at least when MS does a release with a go live for MVC)?

Would like to hear people's thoughts/experiences...

RockfordLhotka replied on Thursday, June 12, 2008

Fwiw, my work has been entirely at the proof of concept level - making sure CSLA works as-is with MVC.

MVC has no data binding, so there's no issue there. An MVC View looks very much like 1997 ASP Classic code - a mix of html and <% %> code. The only real difference is that there are some helpers that make it easier to emit some of the html. I could see some CSLA-specific helpers that generate certain CSLA-specific html fragments, specifically around validation, and perhaps around authorization.

MVC is stateless by default, which can impact your object model design. Specifically, to create a stateless object model you must bastardize a "normal" object model and pretty much only create read-only lists of read-only objects, and single editable root objects. That's kind of painful, but has nothing to do with MVC - it is an artifact of being stateless.

The real key is that CSLA objects provide a Model that encapsulates all the business logic. Some MVC purists seem to think this is bad, but I don't think so. What it means is that you create a View that displays the data from the object's properties (if allowed), and a Controller that calls the object's factory and hands the result to the View.

On a postback, the Controller gets the values from the html form and can use the MVC helper (which looks a lot like Csla.Data.DataMapper) to copy the values into the object's properties. Then it calls Save() on the object and that's it. The only catch here is the normal one around being stateless - the html form must have all the property data, even for properties it doesn't display so it can reload the object from scratch.

Alternately, of course, if you can't put all the property data in the html form, you can just reload the object, then put the form values into it and then call Save(). There's a perf hit obviously, but this is a pretty common solution to the stateless issue - and still only requires 3-4 lines of code in the Controller.

nermin replied on Thursday, June 12, 2008

I have worked both with Csla and MVC, have presented to different groups on both frameworks separately.

I guess I will repeat the same statement that Rocky has made.  There are no issues in using Csla inside MVC project.  Utilizing Csla can actually greatly simplify the design of both Busines and Data Access Layers in a MVC application.

With that said, what do I see as a potential problem?  The key point here is that MVC framework does not utilize databinding, postback model, and does not try to "map" stateless/disconected nature of the web into a web development model that "fakes" stateful (through usages of things as Viewstate, Session, etc).  Due to that, portions of the Csla.Net framework that help with databinding and preserving state (n-pevel undo for example) might become useless in MVC app. 

However thankfully there are many other reasons that you still need Csla, and Csla can help you in design of your MVC application (Predefined set of patterns that deal with object creation loading, mapping, mobile objects, encapsulation of object serialization as a part of the object itself, business and authentication rules, etc...)

Another sticking point, and this is something Rocky has also touched in his answer is what MVC purists keep pointing to is the fact that most of the MVC implementations build their Business layer around one or other Dependency Injection framework.  Dependency Injection meaning that at runtime controller as well as the whole object tree needed by a Controller class can be defined outside of the Controller itself (and the registration of each dependency and how it is created/instantiated can be pushed to a XML configuration file)

This design makes unit testing easier, as you can focus your unit tests only on the unit/object being tested and "fake" these other loosely coupled dependencies (which are basically defined by an interface only)

So this DI model requires a whole set of objects in the Business and Data Access Layer.
Controller Requires Service Object.  Service is in charge of Retreiving, setting, arranging Business Entiity objects (only Controller and Service objects can be "Injected").  Business Entity Objects are returned by a Repository objects which encapsulate data access and/or data mapping of DTOs to Business Objects.

This whole set of objects can be replaced by single Csla object - it acts both as a Service and Enity object, and it can encapsulate Repository features inside itself.  So we are talking then about different approaches to BO layer design.

Why not use CSLA inside of the DI model?  Many argued that you can not "inject" Csla object.  In couple of other discussions in this forum we have proven that false, and I think we have both StructureMap and Windsor examples of "Injecting" Csla object.

There is one problem with Dependency Injection.  You can not "inject" different points individually in the Csla Object hierarchy.  Lets say you have Project object that contains a list of child objects - Assignments.  You can not inject the Repository that loads Project, Repository that Loads Assignments or Assignments themselves, since to Csla Mobile Object feature, root object is created in a completely different context (could be accross network), and that includes creation of data access / repository objects as well as all child objects.  SInce they are not in the same cotext as the DI framework, DI framework cannot construct them. 

And that is the whole problem with Csla.  Its tightly coupled object hierarchy of Root->Child objects as well as encapsulation of data access code, objects is the primary reason that the MVC purist refuse to utilize it in their MVC web implementations.

My point is that:  If you really are not concerned about "loose coupling" of the layers of the App and BOs hierarchies (in other words it is not a business requirement for app you are building) you really do not have to utilize the whole DI approach, and there is no reason not to consider a lot simpler Csla architecture.

Nermin

webjedi replied on Friday, June 13, 2008

So a lingering MVC question that I've had (not necessarily CSLA specific) (mind you I have no experience with MVC outside the Hello World app), if there is no Viewstate or Session, does Authorization have to occur on every request?  Normally we stuff the Principal into a Session variable and use it from there all over the place...with MVC are we passing credentials on each request?  Or does ApplicationContext still take care of that?

Ryan

RockfordLhotka replied on Friday, June 13, 2008

Csla.ApplicationContext doesn’t take care of it, no.

 

If you don’t have Session then you are left with few (all unpleasant) choices for hydrating your Principal object:

 

1.       Serialize the Principal into the authentication cookie – which only works if it is small, because there’s a pretty low size limit on cookies

2.       Reload the Principal from the database on each page request

3.       Reload the Principal from a file or some other temporary store of your creation

 

As you say, this is not a CSLA issue, but rather a stateless web issue. You can encounter this issue without MVC today – just turn off Session on your web site and you face the same problem.

 

I haven’t looked to see if MVC supports Session at all. I suspect it does though, and if it does, then you’d have the option of using Session just like you do today in a typical Web Forms app.

 

Rocky

 

webjedi replied on Friday, June 13, 2008

RockfordLhotka:

I haven’t looked to see if MVC supports Session at all. I suspect it does though, and if it does, then you’d have the option of using Session just like you do today in a typical Web Forms app.

I would hope it does but either it's implied that it doesn't or I'm just improperly inferring that it doesn't.  It would be an ugly world without SOME kind of state persistance on the web...and no cookies don't count. :-)

I just looked on the forums.asp.net site and there are discussions about sessions and MVC and they are supported.

nermin replied on Friday, June 13, 2008

Session is available through HttpContext:

HttpContext.Session["Key"]

 

From: webjedi [mailto:cslanet@lhotka.net]
Sent: Friday, June 13, 2008 11:27 AM
To: Nermin Dibek
Subject: Re: [CSLA .NET] RE: MVC and Csla

 

RockfordLhotka:

I haven???t looked to see if MVC supports Session at all. I suspect it does though, and if it does, then you???d have the option of using Session just like you do today in a typical Web Forms app.

I would hope it does but either it's implied that it doesn't or I'm just improperly inferring that it doesn't.  It would be an ugly world without SOME kind of state persistance on the web...and no cookies don't count. :-)

 



cliffordru replied on Monday, June 16, 2008

Thanks for the replies, this is very helpful.  I will continue to dig into and post anything interesting I come across.

tarekahf replied on Tuesday, February 10, 2009

Dear All,

We are in the process of finalizing the use of a framework like CSLA .NET for application development. I proposed CSLA some time ago, and just recently, some of my colleagues are competing with my proposal with the following arguments:

1. We are moving to VS 2008, and there is no need to use a framework like CSLA. The new features of VS 2008 have all the features of CSLA .NET.

2. CSLA is not a Microsoft product, not supported by Microsoft, it is open-source and free, so it has limited support. We should consider a Microsoft alternative like the newly released ASP.NET MVC.

3. We should consider ASP.NET MVC because it is supported by Microsoft and has all the features of CSLA.

I have made very little research about ASP.NET MVC, so I am not sure if the above arguments are correct.

I need your feedback about the above arguments.

Thank you.

Tarek.

RockfordLhotka replied on Tuesday, February 10, 2009

Comparing ASP.NET MVC and CSLA .NET is like comparing apples and oranges.

ASP.NET MVC is a UI framework that helps you build web interfaces for your application. I like it quite a lot, and it works very well with CSLA .NET. But it does nothing that CSLA does, and CSLA does nothing that the MVC framework does.

CSLA .NET is a business object framework that helps you build a formal business layer for your application. In the MVC world, the CSLA framework helps you build the "M" (Model).

To directly answer your questions:

1. That is false - nothing new in VS 2008 changes the value of CSLA .NET

2. That is mostly true - CSLA .NET is not a Microsoft product, it has limited support (this forum) and it is free. It is arguably open-source. But there is no Microsoft alternative - they don't have a product that does what CSLA .NET does, which is why I created and continue to maintain CSLA.

3. You probably should consider MVC, but as I note above, the two frameworks are entirely different, and work well together.

tarekahf replied on Tuesday, February 10, 2009

Thanks a lot !

So, it looks like MVC will close the loop I was looking for since ever I started this exercise about 1 year ago !

Do you mind if you send me your email contact in case I want to use your reply as a reference, just in case. Probably it may not be a good idea to use this post/forum as a reference.

But, we are now on VS 2005 ... so if we want to use MVC, then we have to upgrade all our PCs and skills to VS 2008, which will involve additional cost/licensing/effort ...etc... correct ?

Tarek.

RockfordLhotka replied on Tuesday, February 10, 2009

I prefer to handle dialog through the forum rather than via direct email. I already get far more direct email than I can manage :)

 

I don’t know what kind of licensing you have today, and I’m not a licensing expert. If you have MSDN or an EA I’m sure you get VS 2008 automatically, beyond that I have no idea.

 

I didn’t find moving from VS 2005 to 2008 to require much learning. They aren’t that different, though 2008 does have some more features and capabilities.

 

I would guess that your learning curve will be mostly with ASP.NET MVC and CSLA .NET, as you’ll need to learn both frameworks.

 

Rocky

Wbmstrmjb replied on Wednesday, July 29, 2009

tarekahf:
Do you mind if you send me your email contact in case I want to use your reply as a reference, just in case. Probably it may not be a good idea to use this post/forum as a reference.


Tarekahf,

If you didn't already know, Rocky is the creator of CSLA and while he is extremely helpful and active in the forum, I don't think he randomly offers his email out on the net. You certainly wouldn't consider asking Bill Gates for his personal email so that you could use him as a reference to defend a Windows vs Mac discussion. Rocky is the Gates of CSLA... just less a few 0's in the checking account. :)

Copyright (c) Marimer LLC