RE: Share a model between multiple edmx files (Entity Framework 4.0)

May 15, 2012 at 5:42 PM


Could you new version solve this issue in the link below? Or some way work around?

BTW, Any progress/update from the work of your new version?

Thanks & Regards…


Dr. Ting-fang Zheng

Lead Software Engineer

Detection & Alarm
UTC Climate, Controls, and Security

Tel: +1 (941) 308 8173

Cell: +1 (941) 209 8085

8985 Town Center Parkway

Bradenton, FL 34202 USA

From: jbudimir [email removed]
Sent: Monday, May 07, 2012 3:44 AM
To: Zheng, Ting fang CCS
Subject: Re: Started work on a new version [t4csla:348556]

From: jbudimir

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?

May 15, 2012 at 9:53 PM

Hi Ting.

The problem you posted is not related in any way to CslaExtension or CSLA framework. What's the point of having multiple instances of the same object on different EF models and the same namespace?

Here are some general recommendations:

If you can switch to Visual Studio 11 then do it, because it comes with new EF designer. By using the new designer you can have one EF model with multiple diagrams that helps you to organize objects into logical units. That way you can keep your solution simple and easy to maintain.

Usually, I split my business objects in two EF models: one for editing "common data" (cities, states etc.), and other for "work data" (orders, inventory, invoices..).

For common data I create database views (CitiesInfo, StatesInfo) and add them to WorkModel as read-only objects used for lookup lists.

My rule of thumb is "what needs to be written in one transaction should be in the same EF model".

I'm not sure if I understood everything, so if you have any additional questions feel free to ask.