This question is locked. New answers and comments are not allowed.
Hi everyone. I've been trying to update my ORM to a Domain Model, and let me tell you, that was no fun. The upgrade destroyed all relationships between tables (No Targets!). No fun at all. Anway, I decided to create a clean one, and that worked out okay, but have some questions....
1) I have a Customer table and a CustomerAddress table. There are five different FK's to CustomerAddress from customer, for five different address types. By default (old and new), the orm creates "CustomerAddress1, CustomerAddress2.... etc, under customer. In the old ORM, it was simple to identify which one was which (and thus rename). In the Domain Model, there is NOTHING in the GUI that shows what they are . I have to open the underlying .cs file to find out, and then go back to the gui and rename. That's kind of dumb, isn't it? Is there another way to identify them. There is nothing in properties, that's for sure, nor is there anything in properties under the OpenAccess Model Explorer. There are properties for them, but none that identify at least source and target fields. Just that would be helpful.
2) My database contains about 150 tables (Thank God their aren't any SP's). Even compiling everything into one file, the GUI and updates to the GUI are pretty darn slow. It's also a visual nightmare with all the association lines going back and forth. It would be nice if I could create a subset diagram off of the main one, that just holds a collection of objects I want to work on. For example, all (or most) tables related to the Customer Table only, in one diagram, Another of tables related to the Item table. There would be overlap, but as they would be subsets of the main diagram, it could be kept in sync, and the UI should be faster. Even if they were temporary, it would be helpful.
3) The Context file that is generated pluralizes all the routines. I've never understood this philosphy and am totally against it. You can control this now with classes, fields, and properties, but there is apparently no control for the context file that is generated. Why would I want a routine called AccountActivities for my table AccountActivity. I understand what its trying to do, I just don't like or agree with it.
4) The "Locate in Diagram" feature doesn't work well at all. At least on bigger models.It apparently can do horizontal position fairly well, but fails miserably on vertical position.
If it sound like I am trying to trash the Domain Model, I apologize, that's not my intent. I'm just finding some of the new stuff, a little tweaky and I'm hoping at least some of this stuff is being looked at.
Thanks in Advance!
Greg
1) I have a Customer table and a CustomerAddress table. There are five different FK's to CustomerAddress from customer, for five different address types. By default (old and new), the orm creates "CustomerAddress1, CustomerAddress2.... etc, under customer. In the old ORM, it was simple to identify which one was which (and thus rename). In the Domain Model, there is NOTHING in the GUI that shows what they are . I have to open the underlying .cs file to find out, and then go back to the gui and rename. That's kind of dumb, isn't it? Is there another way to identify them. There is nothing in properties, that's for sure, nor is there anything in properties under the OpenAccess Model Explorer. There are properties for them, but none that identify at least source and target fields. Just that would be helpful.
2) My database contains about 150 tables (Thank God their aren't any SP's). Even compiling everything into one file, the GUI and updates to the GUI are pretty darn slow. It's also a visual nightmare with all the association lines going back and forth. It would be nice if I could create a subset diagram off of the main one, that just holds a collection of objects I want to work on. For example, all (or most) tables related to the Customer Table only, in one diagram, Another of tables related to the Item table. There would be overlap, but as they would be subsets of the main diagram, it could be kept in sync, and the UI should be faster. Even if they were temporary, it would be helpful.
3) The Context file that is generated pluralizes all the routines. I've never understood this philosphy and am totally against it. You can control this now with classes, fields, and properties, but there is apparently no control for the context file that is generated. Why would I want a routine called AccountActivities for my table AccountActivity. I understand what its trying to do, I just don't like or agree with it.
4) The "Locate in Diagram" feature doesn't work well at all. At least on bigger models.It apparently can do horizontal position fairly well, but fails miserably on vertical position.
If it sound like I am trying to trash the Domain Model, I apologize, that's not my intent. I'm just finding some of the new stuff, a little tweaky and I'm hoping at least some of this stuff is being looked at.
Thanks in Advance!
Greg