I just started using CSLA 4. For my BO, I have 2 projects, one for the server and another for the client. The Server code contains all the DataPortal_XXX methods plus the shared business methods. The client code only has the static Factory methods plus the shared business methods. My target deployment is via WCF communication with Windows Auth. So far everything is ok until I get to implement DataPortal_Create methods.
What I noticed is that the DataPortal_Create (with or without parameters) is only invoked using the LocalProxy. It defaults to invoking DataPortal_Create(). I have played around with the code but for me to invoke the DataPortal_Create(param) in the remote host, I have to add the DataPortal_Create(param) in the client BO with empty code body. I do not have to do this with the DataPortal_Fetch methods. I am still using the synchronous method invocation.
Am I doing anything out of the ordinary?
Client Code :
public partial class FiscalYearBudget
#region Factory Methods
public static FiscalYearBudget CreateBudget(int FiscalYear)
CreateFYBudget criteria = new CreateFYBudget();
criteria.FiscalYear = FiscalYear;
// if I uncommented this method, this gets invoked in the Remote Host.
//private void DataPortal_Create(CreateFYBudget criteria)
When you say two projects, this makes me think you are using Silverlight? If you are using .NET you'd have one business class library that is deployed to both client and server.
Either way, you need to configure the client's data portal to invoke the server. The configuration is a little different between Silverlight and .NET, but basically involves setting the CslaDataPortalProxy to something like WcfProxy and providing the URL of the app server.
Thanks for responding Rocky. Today is Saturday and should be a no work day
Sorry I was not clear on this. I thought the synchronous call and the DataPortal.Create invoke in the code made it clear that we are doing Win/WPF projects. We like the separation of the server side and client side code in the projects so we lay it out that way so we do not deploy db code on the client. this worked fine even on CSLA.NET 3.04 and if we have to go the silverlight way we are already set. It also helped us in clickonce deployment since ODP.NET seems to want to be installed in the client machine which we can not do at the moment. The separation of the client and server code made our clients not depend on Oracle. Anyway, it works on the DataPortal.Fetch and DataPortal.Update calls and it will not be a problem having the DataPortal.Create methods in the client code.
Copyright (c) Marimer LLC