I'm generating some class diagrams from existing code to improve the documentation but I've run into a bit of an obstacle. I'd like to show collection associations on the diagram, but for interfaces this just doesn't seem possible.
If the interfaces are in another assembly, the collection type is displayed in its unbounded form (e.g. ReadOnlyObservableCollection1`) and attempting to display collection associations gives the error
This is not a valid type name.
If the interfaces are in the same assembly, the collection type is displayed in its bounded form (e.g. ReadOnlyObservableCollection`), but attempts to display the associations come out with the error message
Cannot show an association because cannot be found.
Any ideas what I'm doing wrong, or is this just a shortcoming of VS class diagrams?
Thanks,
James
I found that by removing and removing and re-adding the reference of the assemble containing the offending class, solved the issue.
Related
I have developed a system where various classes have attributes consisting of a custom formula. The formula can contain special tokens which refer to different types of object. For example an object of class FruitSalad may have the following attribute;
$contents = "[A12] + [B76]";
In somewhat abstract terms, this means "add apple 12 to banana 76". It can also get significantly more complex than that with as many as 15 or 20 references to other objects involved in one formula.
I have a trait which passes formulae such as this and each time it finds a reference to a model (i.e. "[A12]") it gets it from the database with A::find(12) and adds it to an array of component objects which can be used for other processes later on in the request.
So, in essence, it's a relationship. But instead of a pivot table to describe the relationship, there is a formula on the parent model which can include references to child models.
This is all working. Yay! But it's really inefficient because there are so many tiny queries to get single models as formulae are parsed. One request may quite easily result in hundreds of queries. Oops.
I see two potential options;
1. Get all my apples and bananas from the database at the start of the request and get them from an in-memory store instead of from the database when parsing a formula (is this the repository pattern??).
2. Create a custom relation type (something like hasManyFromFormula) which makes eager loading work so that the parsing becomes much simpler because the relevant apples and bananas would already be loaded into the parent model.
Is there a precedent for this? As for why I am doing it like this, it would a bit tough to explain in brief but suffice to say it is to support a highly configurable data retrieval system which supports as-yet unknown input data configurations.
Help!
Thanks,
Geoff
Am not completely sure if it is the best solution, but in the end I created a new directory class for basic components and then set it up in the app service provider as a singleton. The constructor for the directory class loaded all models of several relevant classes and made them available as collections throughout the app.
I'm quite new to MVC3, just learning and am looking for some guidance.
For sake of simplicity, I have a model that represents 3 types of elements, questions, answers and containers.
All 3 inherit from a common base type, which I'll call baseElement.
When the model is delivered to the view it is a single object of type 'baseElement'
The container elements have an internal list of baseElements.
Those baseElements can be of any of the three types. So - containers can contain questions, or containers (which could also contain questions, containers, etc..)
Each question can contain different types of answer types.
I'm trying to figure out how to use mvc3 to best implement a system to display this container/question structure to the user - permitting them to answer questions with various answer types while respecting the nested structure of the incoming model.
Alright, despite the dynamic nature of my model, after poking around for awhile longer I've been able to render my model object structure without too much complication.
I did it by using a strongly typed Editor Templates (one for each type), and the following code in the View.
#Html.EditorFor(x => #Model, #Model.GetType().Name)
This automatically chooses the proper editor template to use based on the actual type.
In each of the type specific Editor Templates I make the same call for each of the children.
It actually ends up being pretty simple.
The big problem I'm running into now, is how to model bind (or otherwise retrieve) the form values back into something usable once it's posted by the user. The dynamic nature of the structure causes the default model binder to cross it's arms and give up.
At this point I think retrieving/remapping the form data might be a much bigger issue, but that will certainly require more tinkering, and perhaps a separate question.
Thanks for the help.
:-)
We're looking for a way to document Core Data entities. So far the only real options I've come up with are:
Document externally using UML or some other standard
Create NSManagedObject subclasses for every entity and use code comments
Use the User Info dictionary to create a key value pair that holds a string comment
Option 1 feels like too much extra work and something that will almost certainly be out of date 99% of the time.
Option 2 feels natural and more correct than option 1. The biggest con here is that those comments could potentially be lost if this model class is regenerated using Xcode.
Option 3 feels a little less correct than option 2, but has the added advantage of adding automation possibilities with regards to meta data extraction. For instance, in one of our apps we need to keep a real close eye on what we're storing locally on the device as well as syncing to iCloud. Using the user info dictionary it's pretty easy to automate the creation of some form of artefact which can be checked both internally and externally (by the client) for compliance
So my question is whether it would be inappropriate to use the user info dictionary for this purpose? And are there any other options I'm missing?
Option 2 is what I use every time. If you look at your core data model (something.xcdatamodeld or something.xcdatamodel) you will see something like the picture below.
You can tie your entity to whatever class you want and then put the comments in there. It helps if you keep your entity name the same as your class name to make it obvious what you've done.
Additionally this also gives you the ability to add automation. You can do this by creating custom getters and setters (accessor methods) and a custom description method.
I use option 2 and categories. I'll let XCode generate the NSManagedObject subclasses and use a categorie on each of these subclasses. With the categories I do not loose my changes made in the categories, can document, make custom getter and setters and I am still able to use generated subclasses.
If we speak only about documenting (i.e. writing more or less large amounts of text which is intended to be read by humans) your classes, I'd use the option 2.
If you are concerned with the possibility of Xcode overwriting your classes in the option 2, you may consider creating two classes for each entity: one which is generated by Xcode and always could be replaced (you generally do not touch this file) and one other which inherits from the generated one and in which you put all your customizations and comments.
This two-class approach is proposed by the mogenerator.
Although if you need to store some metadata with the entities which will be processed programmatically, the userInfo is perfectly suitable for this.
I have an existing database, which I have been happily accessing using LINQtoSQL. Armed with Sanderson's MVC3 book I thought I'd have a crack at EF4.3, but am really fighting to get even basic functionality working.
Working with SQL 2008, VS2010, the folder architecture appears to be:
ABC.Domain.Abstract
ABC.Domain.Concrete
ABC.Domain.Concrete.ORM
ABC.Domain.Entities
Per examples, repository interfaces are abstract, actual repositories are concrete. Creating EDMX from the existing database puts that in the ORM folder and the Entities holds the classes I designed as part of the domain. So far so good.
However! I have not once persuaded the deceptively simple EfDbContext : DbContext class, with method to work...
public DbSet<ABC.Domain.Entities.Person> Person { get { return _context.Persons; }}
It complains about missing keys, that Person is not a entity class, that it cannot find the conceptual model, and so on.
Considering I have a basic connectionstring in the web.config, why is not creating a model on the fly to do simple matching?
Should the ORM folder exist, or should it simply be Concrete? (I have a .SQL subfolder for LINQtoSQL concret so it suits me to have .ORM but if it's a flaw, let's fix it).
Should I have my homespun entities AND the automatically produced ones or just one set?
The automatic ones inherit from EntityObject, mine are just POCO or POCO with complexTypes, but do not inherit from anything.
What ties the home designed Domain.Entities.Person type to the Persons property of the Context?
Sanderson's book implies that the matching is implicit if properties are identical, which they are, but that does not do it.
The app.config has an EF flavoured connection string in it, the web.config has a normal connection string in it. Which should I be using - assuming web.config at the moment - so do I delete app.config?
Your help is appreciated. Long time spent, no progress for some days now.
What ties the home designed Domain.Entities.Person type to the Persons
property of the Context?
You seem to have a misunderstanding here. Your domain entities are the entities for the database. There aren't two sets. If you actually want to have two sets of object classes (for whatever reason) you must write any mapping between the two manually. EF only knows about the classes which are part of the entity model.
You should also - if you are using EF 4.3 - apply the DbContext Generator T4 template to the EDMX file. Do not work with EntityObject derived entities! It is not supported with DbContext. The generator will build a set of POCO classes and prepare a derived DbContext. This set of POCO classes are the entities the DbContext will only know about and they should be your only set of domain entities.
The created DbContext will contain simple DbSet properties with automatic getters and setters...
public DbSet<Person> People { get; set; }
...and the Person class will be created as POCO as well.
Download the entity framework power tools:
http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d
Right click in your project to 'reverse engineer an existing database' it will create the code classes for you. No need to use EDMX ,and this method will create the DbContext derived class for you
There are many questions here and you won't get an answer, but I'll stick my 5 pence for what it's worth.
Sanderson's MVC3 book
Your problems are not to do with MVC3, they are to do with Entity Framework and data persistence layer.
ABC.Domain.Abstract ABC.Domain.Concrete ABC.Domain.Concrete.ORM
ABC.Domain.Entities
Can you say why this is separated in such a way? I would argue and say that ABC.Domain should contain your POCOs independent of your persistence layer (EF) and your presentation layer (MVC). Your list implies that your domain contains ORM and your data access entities. I'm not arguing here, what I'm trying to say, is that you need to understand what you really need.
At the end of a day, I'm certain that a simple example would suffice with ABC.DataAccess, ABC.Domain and ABC.Site.
Do you understand why repositories are abstract and concrete? If you don't, then leave out interfaces and see whether you can improve it with interfaces later.
Person is not a entity class, that it cannot find the conceptual
model, and so on.
Now, there are multiple ways you can get EF to persist data for you. You can use code first, where, as the name implies, you will write code first, and EF will generate database, relations and all the relevant constraints for you.
You can use database first, where EF will generate relevant class and data access related objects from your database. This is less preferable method for me, as it relies heavily upon your database structure.
You can use model first, where you will design your class in EDMX designer and it will then generate relevant SQL for you.
All of these might sound like a bit of black box, but for what you are trying to achieve all of them will work. EDMX is a good way to learn and there are many step by step tutorials on ASP.Net.
but if it's a flaw, let's fix it).
You will have to fix and refactor yourself, there is no other way to improve in my honest opinion. I can give you a different folder/namespace structure, but there will always be a "better" one.
Should I have my homespun entities AND the automatically produced ones
or just one set?
Now this depends on the model that you have chosen. Database first, code first, code only and whatever else is there. If you are following domain driven development, then you will have to work with classes, that represent your business logic and that are not tied up to your data persistence layer or presentation layers, therefore POCO is a way forward.
What ties the home designed Domain.Entities.Person type to the Persons
Now this again depends on the model that you are using.
The app.config and web.config
When you are running your web application, the connection string from web application will be used. Please correct me if I'm wrong.
Your help is appreciated. Long time spent, no progress for some days
now.
General advise, leave MVC alone for the time being. Get it to work in a console application and make sure you feel comfortable with options offered in EF. Good luck :)
The solution to why nothing worked code-first...
...turned out to be a reference to System.Data.EntityClient in the connection string, which ought to have read System.Data.SqlClient.
Without this provider entry being correct, it was unable to work code-first.
Finding which connectionString it was using was a case of deliberately mis-spelling a keyword in the connections there were to choose from - they all were named correctly - but were in app.config, and 2 places in the web.config. With a distinct naming error, when the application threw an error trying to create the domain model, it was easy to identify which connection string my derived DbContext class was using. Correcting the ProviderName made all the difference.
Code-first is now working just fine, with seeded values on model changes.
I'm throwing this out in case someone has encountered this before.
When creating DesignData for use within the WPF designer, I get one of two errors:
Object does not match target type.
at System.Reflection.RuntimeMethodInfo.CheckConsistency(Object
target)
(SNIP)
at Microsoft.Expression.DesignModel.InstanceBuilders.ClrObjectInstanceBuilder. UpdateProperty(IInstanceBuilderContext
context, ViewNode viewNode, IProperty
propertyKey, DocumentNode valueNode)
The other one is a little more informative:
The value "_.di0.MyProjectLol.MyType"
is not of type "MyProjectLol.MyType"
and cannot be used in this generic
collection.
at
System.ThrowHelper.ThrowWrongValueTypeArgumentException(Object
value, Type targetType)
(SNIP)
at Microsoft.Expression.DesignModel.InstanceBuilders.ClrObjectInstanceBuilder.
InstantiateChildren(IInstanceBuilderContext
context, ViewNode viewNode,
DocumentCompositeNode compositeNode,
Boolean isNewInstance)
When debugging, I can see that there is a dynamic assembly that is loaded with proxy-ish types that look like mine but, obviously, are not. This assembly is called Blend_RuntimeGeneratedTypeAssembly(Guid goes here). When attempting to load types in this assembly, it throws a type load exception for a number of them. So, some types get proxied, some types are left as God and I intended, and when they mix unnatural acts occur.
For example, the type "Foo" might get a proxy created, but no other types do (TypeLoadExceptions). Then the designer tries to hand one of my real types the proxy (helped by the fact that xaml serialization likes to cast collections to IList, thus shitting on type safety) and you get one of the above exceptions.
I have spent half a week trying to fix this. I've tried a hundred different things, but I can't figure out exactly what is causing it to fail. Suggestions are welcome, TIA.
Solution in two parts:
1) Ensure VS is fully updated. At this point, it means installing the Silverlight 4 tools for Visual Studio 2010. They include the latest updates to the WPF designer. If you're reading this off in the distant future, ignore this one.
2) Hit the properties for your design data files. Clear out "Custom Tool", and set the "Build Action" to either "DesignData" or "DesignTimeDataWithDesignTimeCreatableTypes".
DesignData means that your types cannot be deserialized from xaml directly (due to dependencies or the such), so the designer attempts to create mocks for those types and presents the mocks to your design surface.
DesignTimeDataWithDesignTimeCreatableTypes means that the designer will load your assemblies and deserialize the xaml directly into your types without creating mocks.
This can also be caused by a certain combination of situations that, when combined, cause deserialization to fail.
Essentially if you have
A custom collection, or a collection that doesn't implement IList
That is exposed as a property on your type
Which is defined in a different assembly
you can get this error message as well.
It is very important that your collection property types implement IList (the non-generic one) if you want to serialize them to and from xaml!