CSLA and Modeless Forms

CSLA and Modeless Forms

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


estaylorco posted on Sunday, November 16, 2008

Hello, Forum:

I'm only about a week into CSLA.NET (after lurking about for about six months).  Currently, I'm using the DevExpress control suite on the front end, and XPO on the backend.  I'm refactoring away from XPO in favor of LLBLGen Pro.  My intention is to unify a DevExpress UX and an LLBLGen Pro DAL under CSLA, and then abandon my shell.

After working with XPO for over a year now, I was surprised just how much modeless forms in the UI influenced the architecture of my shell, specifically in the presence of XPO.  The notion of "session" is devastating.  My forms derive from a base class and support tine passing in of CallbacksArgs in their constructors (CallbackArgs encapsulates SaveAndCloseCallback, ApplyCallback, NavigationRequestCallback, and CancelCallback).  The callback pattern specifically supports modeless forms, but it doesn't play well with XPO due to anchoring to a session and the behavior of the cache.

Does CSLA.NET take issue with modelss forms?  Are their any peculiarities or ideosyncrasies that I should be aware of?

Thank you.

Eric

RockfordLhotka replied on Sunday, November 16, 2008

I'm afraid I don't have any context for most of what you are talking about.

However, I do know that data binding can complicate the use of modeless forms. If you have more than one form binding to a single business object, data binding will get very confused. Each form's bindingsource (I'm assuming Windows Forms) will assume it "owns" the object, and the 2+ bindingsource objects will fight each other.

This isn't so much a CSLA issue, as a data binding issue, but is certainly something to be aware of.

If you don't share object instances across forms, then this is a non-issue, and I can't see where CSLA would care if your forms are modal or modeless. CSLA doesn't have anything to do with navigation or other UI concerns.

estaylorco replied on Sunday, November 16, 2008

Rocky,

Thank you for your reply.

The UI management portion of my shell manages forms in such a way as to prevent more than one form's accessing the same business object simultaneously.  For example, forms are opened with TryShow(...) instead of just Show().  If a form is already open onto a business object, TryShow() will simply bring it to the front.  (This gets even more interesting when a visual tree in the UI is the springboard for creating or editing business objects).

In any case, you answered my question.

By the way, Rocky, I purchased your 2005 C# book, along with your two eBooks not long after, and I must say that you are an excellent writer (and speaker).  I learned more about architecture in the first 30 pages or so of your book than I've ever learned elsewhere.  No kidding.  These books, together with your DNR-TV recordings, have given me deep insight into application development under .NET...and in general.

I think you and Franz Bouma (of LLBLGen Pro fame) are two of the most thoughtful software developers out there.

Thank you for your hard work.

Eric

Copyright (c) Marimer LLC