Started work on a new version

Mar 14, 2012 at 1:05 PM
Edited Mar 14, 2012 at 1:07 PM

Hi all.

I've started work on a new version of the extension.

Plan is to upgrade extension in order to support new features in Entity Framework and CSLA. Also I'll try to refactor code a little bit, and improve user experience regarding installation and project setup.

I'll also try to create a nuget package for this extension.

Regards, Josip

Mar 14, 2012 at 3:59 PM

Hi great news!

What version of Entity Framework and what version of CSLA do you plan to support?


Mar 15, 2012 at 8:03 AM

Hi Mike,

I'll make changes for EF 4.3 and CSLA 4.3 versions (with support for Visual Studio 2011, EF diagrams etc).

I have already implemented the DbContext support and it will be recommended template for future use. DbContext is much simpler then ObjectContext and some scenarios are much easier to implement.




May 4, 2012 at 10:57 AM

Hi Josip,

I really like the concept of using CSLA business objects with EF 4.3 and especially using code first. I would really love to know how you are currently using this framework? Could you please provide sample application which uses advanced concepts like Unit of Work pattern to save multiple round trips to server etc.

I can understand you are too busy with your current work and won't be able to finish this project in near future. I would love to contribute to this project if possible. You can guide me in that direction.


May 4, 2012 at 11:02 AM

Hi Josip,

Are you planning to use DbContext in the manner described in following post?


May 4, 2012 at 11:18 AM

Hi powertoy.

What kind of app are you interested in? Web, Windows Forms, Silverlight?

I use EF/DbContext only for data access. Every object in my application is a CSLA object with backing properties, business rules, data access methods etc. Entity Framework is used only to read and write CSLA object properties to the database. DbContext is used instead of ObjectContext just to simplify some scenarios like graph loading/saving.

Unit of work pattern is not necessary when using CSLA, because all related objects should be contained by one "main" object for each use-case scenario. That "main" object is your UnitOfWork for concrete scenario.

I hope that I was clear enough. Feel free to ask if you have more questions. 


May 4, 2012 at 2:38 PM

Hi Josip,

Thanks for quick reply. I am working as a Middle tier developer and responsible for designing classes and their behaviors. I am using Windows Forms as front end. I fully agree with you that DbContext is only for data access. Unit of work pattern is useful when suppose I am developing a Customer form. On Customer Edit form suppose I need to show combo boxes for city, state etc. How can I get all these along with actual customer CSLA object in a single request? So that I get all combo related stuff in different request but only once, and get selected customer data in separate request when selected for edit in list screen. I was asking can we have facility to create new class which is not mapped to database and implements UoW?

Another question is, are you planning to use CSLA classes directly with DbContex or for that we will create POCO and CSLA classes with use these POCO internally to offload database related stuff?

Thanks a lot

May 7, 2012 at 7:43 AM

You are mixing read-only data like cities and states with editable data (Customer). Also, in your example you have a read-only list of customers and editable object Customer. Those objects have different uses and should be separated. Most likely, some of that data will be cached on the client (cities?). 

I would use this approach:

1. Create database view for CustomersList that contains all data that should be presented in the CustomersList form

2. Create read-only business list to display customers on one form

3. Create editable-root for editing of one customer

4. Create read-only lists to fill combos (states, cities) on the customer edit form (even better, create user controls for them)


About POCOs: I use EF diagram to model CSLA business objects, and then use POCOs internally to load and save those objects to the database. Working that way you can separate database and business domains (encapsulation).

If you want, I can help you create small sample app?