Hi
I am using the CSLA framework for a time and I want to integrate it in the smart client software factory environment. So I love the idea of creating for a given module (a dll in this environment) another "Interface" module, so other modules in the solution make a reference to the "Interface" module and not to the Module that conatins the Business entities (that use CSLA framework).
In another word, if I create a BusinessObjects module (that use CSLA),I want to create another module (BusinessObjects.Interface module) that contains the interfaces that BusinessObjects will implements. this way any module in the solution will refere to the Interface module (businessObjects.Interface) and not the real BusinessObjects module...
This is a pattern in this environment. the idea is that i can now change BusinessObjects module without affecting all the other modules in the solution because they are not coupled to the changed module.
the problem now that if i create an Interface in the Interface module named ICustomersListService that BusinessObjects module will implement by the class CustomersListService that is a read only list of customers, i will not benefit from data binding at design time. because in the module that implement the View, i refere to BusinessObjects.Interface module that contains an interface and not the real business objects. so any idea ?
by the way, I can say that a CSLA business objects are Business entities or not ? and what is exactly a service is ? ( in the SCSF environment )
I think that CSLA is always coupled to the UI (or the View)
I ask if there is any level of indirection between CSLA and the UI.
It is not always the case that the View want to Bind it self directly to the model. I want an iterface in the middle.
I have created dump business entities that play the role of the interface. so the View is bound to those business entities ( as Roky does in ProjectTraker solution, in PTWebService project), but this way I lose the validation in the UI...
In SCSF you should think of a service as a chunk of the application that will be used by lots of other chunks. In our app, for example, we have a ReferenceDataService that supplies lists for drop-down lists via a cache. In a way, services act as 'global' objects for the application.
As for design-time data binding, I would have thought you could bind directly to the business object (i.e. CustomersList) at design-time and then programmatically bind to the output of your service at runtime.
FWIW, we decided that there was enough indirection inside SCSF as it was and we have our modules talk directly to the CSLA business objects. Why? Well, being pragmatists we figure that the chances of wanting to deliver a change to the UI where there was no change to the business object layer was very small. In our project only one team will be responsible for the application, so for us most of the advantage of SCSF comes from the fact that once the UI framework is deployed, then you can deliver application updates by xcopy-ing the module dlls.
AAKLebanon:
Thinks a lot, but i am now asking: what is the difference between a Service and a Command ?
Quoting http://forums.lhotka.net/forums/ShowThread.aspx?PostID=10161#10161
Commands enables you to assign the same executable code to multiple UIElements. This can be useful when you have a toolbar button and menu item that execute the same code and when you have multiple menu bars that contain similar items applicable to different SmartParts.
A Service is a supporting class that provides functionality to other components in a loosely coupled way.
In the CAB, the term service describes a component that implements some infrastructure-related functionality that other components in the application may need to use; for example, services providing authorization, logging, or hardware communication functionality. It does not mean a Web service.
Remember Services are components of WorkItems. A WorkItem exposes a Services property that you can use to add a service to the WorkItem.
The CAB includes a set of basic services that you can use in your applications (eg. ModuleLoaderService). The ModuleLoaderService uses the information returned from the service implementation of IModuleEnumerator to determine which modules should be loaded at run time. You can also build your own services that provide infrastructure capabilities specific to your applications.
It might be interesting to take a look at http://www.codeproject.com/useritems/SCSF_CSLA_ProjectTracker.asp
It's a covertion of ProjectTracker to SCSF.
Best regards
Tiago
thinks for all members. I will now try to make decision in my project even that i am not happy with the idea that i am always obliged to couple the UI assembly (module) with the DomainModel assembly.
and the problem will be propagated to all the projects in my solution. because in one module i want to raise an event that say "SelectedEmployeeChanged(selectedEmployee as EmployeeInfo)"
EmployeeInfo is a business object defined in DomainModel module.
now i want the Shell Module and other modules in the project (event other modules that other users can create, for example a plug in) to subscribe to this event . So the other modules are obliged to make a reference to the DomainModel module !!
so they are always coupled to DomainModel module, so any change in this module will break the other modules !!!
I want to be able to wrap the business objects in an interface and register it as a service, but the problem is that data binding will not work with the interface !!
of corse i can programmatically do data binding and not depend on the design time facilities, but this will take more work ...
thinks for all memebers again and i hope that i can see my dream become a rality...
Copyright (c) Marimer LLC