Connect table in another namespace

Discussion of open issues, suggestions and bugs regarding LinqConnect – Devart's LINQ to SQL compatible ORM
Post Reply
afva
Posts: 39
Joined: Thu 13 Aug 2009 21:22

Connect table in another namespace

Post by afva » Wed 23 Nov 2011 09:12

Hello,

Let us say I have an application that is divided in 3 sections: Financial, Technical and Administrative. Each section has its own Namespace and its own LinqConnect Model.
Now, the 'parent'-table off all tables is the same in the three sections.
Until now, I copied this table three times, once for every section.
This works fine, but I wonder if it is possible to declare this table once in a sort of overall-Namespace and still make associations form this table to the tables in the different namespaces.

Is this possible?

Thanks in advance

StanislavK
Devart Team
Posts: 1710
Joined: Thu 03 Dec 2009 10:48

Post by StanislavK » Thu 24 Nov 2011 16:51

As far as I can understand, you've added a mapping to a particular table to each of your LinqConnect models, and want to move the corresponding entity type to a separate namespace. Am I correct?

Entity Developer does not provide the possibility of specifying the namespace of a single entity type. We will consider implementing such a possibility and post here about the results. You can also add this suggestion to our Uservoice:
http://devart.uservoice.com/forums/3867 ... -developer

At the moment, you should be able to perform this task manually, though this needs changing the generated code. I.e., you can move the 'parent' entity class to the proper namespace manually, and remove the implementations of this class from the code generated for the models. After that, you have to specify the namespace in all references to this class in the model code (e.g., replace all 'Parent' entries with the 'ParentNamespace.Parent' ones). If you are using the XML mapping, you would also have to change the mapping files of your models (precisely, to add the namespace prefix to the Name property of the Database.Table.Type node).

Please tell us if this helps.

afva
Posts: 39
Joined: Thu 13 Aug 2009 21:22

Post by afva » Thu 24 Nov 2011 17:40

Hello StanislavK,

I didn't make myself very clear I guess.
Let's try again:
Because I don't want to have all my tables in 1 linqConnect model, I seperated them in 3 models: AdministrationModel, FinanceModel and TechnicalModel.
There is one table(view) that is the MasterView off all tables, so this table is part of every model. This MasterView is also set as the dataContext
When I want to access the other tables in XAML, I can do that by referring to the association (ForeignKey). Works great.

Now, it seems a bit silly to duplicate the masterView in the 3 models.
So, I put this masterView in a seperate model.
At first, this seems o.k. because I can still refer to this masterView in my C#-code.
Problem is, that I can not make an association from the MasterView to the detail-views, because they are in a different model and that means that I can no longer set this masterView as the dataContext and have the detail-views filled automatically.

Is there a way I can make this work without copying this table 3 times?
I was hoping there was something like 'inheritance' or so?

Thank you

StanislavK
Devart Team
Posts: 1710
Joined: Thu 03 Dec 2009 10:48

Post by StanislavK » Fri 25 Nov 2011 16:06

To perform the task you've described, it is necessary to
a) create navigation properties for all relationships with this 'main' table in both 'detail' entity classes and the 'master' one;
b) add the information about these relationships to the mapping source (e.g., attributes or a file).

If the 'master' and 'detail' classes belonged to the same model, Entity Developer would perform these operations automatically when generating the code. For entities from different models, it won't, as it is not possible to create an association to an entity from a different model. However, you can do this manually, e.g., by modifying the generated code as it is described in my previous post.

Anyway, could you please specify the purpose of splitting a model into several parts, so that we were able to suggest a better solution?

Post Reply