I'm currently working on a WPF-application (C#, using the Prism framework) that will contain a drawing pane where a user can draw polygons using his mouse.
But I'm wondering how I can make these drawings persistent.
I'm guessing that the best object to contain those drawings are the Polygon object?
I would also like to have those Polygons have certain attributes, such as a color etc. (if need be I can do this by defining my own Polygon-inherited object).
But I'm especially wondering how I can make this kind of information persistent in a database? (I'm using SQLite at the moment).
I want to be able to store Polygon information, including information such as the fill-color of that Polygon etc. in a database.
I've been googling this, but I'm not finding something useful. Could someone point me in the right direction?
Thanks for any help!
You have to create model classes in order to store the necessary information, which you would like to store.
I think it might be the best solution to use Entity Framework, so you wouldn't have to bother with creating the model classes, you could use the existing ones. But, in your case, it might saves a lot of unnecessary information into your tables.
If you are creating your own model classes, you can add a helper Extension Method to .net types, such as Polygon. That method would generate a storable model class from the .net class, which can be saved to database.
For example:
Model class:
public class PolygonDbFormat // the class which contains the information you want to store
{
public string Name { get; set; }
public Brush Fill { get; set; }
}
Defining the extension method:
public static class PolygonEx
{
public static PolygonDbFormat AsDbFormat(this Polygon polygon)
{
return new PolygonDbFormat
{
Name = polygon.Name,
Fill = polygon.Fill
};
}
}
Then you can save the Polygon class to the database this way:
var dbFormat = yourPolygon.AsDbFormat();
_yourDbManager.AddEntry(dbFormat); // your implementation to store the data in database
Related
In brief
I'm after suggestions for how best to write a .NET application that provides a design canvas that will allow a user to create an object graph.
In more detail
Imagine the following .NET POCO class
public class BuildingBlock
{
public string Name { get; set; }
public BuildingBlock? Child { get; set; }
}
You can see that someone ccould create an object graph in the following manner:
BuildingBlock start = new()
{
Name = "One",
Child = new()
{
Name = "Two",
Child = new()
{
Name = "Three"
}
}
};
But, my user is not a programmer. They need to create this, but want a nice UI where they can drag 'n' drop objects, or right-click on the screen and pick "new block" etc. For those familiar with it, it would be similar to the design canvass in the Power Virtual Agents (PVA), or the designer in SQL Server Management Studio (SSMS).
I'd of course need to validate the model - so the Name property may have rules around it, such as it must be no longer than 5 characters, and can't contain numbers (simple for a Regex test). I may have a rule that the object graph can only be 12 objects "deep".
This program could save a serialized version of the object graph (xml, json etc). So also, it could read in this serialized file and paint a representation on the canvas for further editing.
Obviously my actual class would be far more complex than the one shown, but you hopefully get the gist.
What would be the best way to approach this, from a .NET perspective? I'm not sure which libraries etc I should look at. This could be a desktop app, or web/blazor.
Look up a tutorial on WinForms TreeView control which supports drag and drop, and context menus. What you will learn will be translatable to other UIs. As Henk mentioned, you need a collection of child nodes List<BuildingBlock> Children, not just a single BuildingBlock? Child.
If you want to record this in a relational database, each node will need to record a reference to its parent, e.g. Guid? ParentId.
I'm planing to create an application to sort and view photos and images I have.
I want to give the program a list of folders (with subfolders) to handle and tag images with multiple, custom tags as I go through them. If I then enter one, or multiple, tags in a search bar I want all images with that tag to appear in a panel.
The go to approach would be SQL, but I don't want to have a SQL server running in the background. I want the program to be fully portable, so just the exe and maybe a small amount of files it creates.
I thought I would create a tree where every node is a folder and the leafs are the images. I would then add the tags of the leafs to the parent-node and cascade that upwards, so that the root node has a list of all the tags. This should allow for a fast search and with parallelisation for a fast building of the tree.
But before I start to work on such a tree I wondered if there is already something like this, or if there is a better approach?
Just to make it clear, I'm talking about multiple tags here, so a Dictionary won't work.
Tags by definition are unique and so cry out to be indexed and sorted.
A Dictionary<Tag,ImageCollection>. Why not? Seems ideal for tags.
A Dictionary<Image, TagCollection>. The reverse reference of the above. You don't want to try going through dictionary values to get at keys.
Create custom classes. Tag, Image, TagCollection, ImageCollection; then override Equals, GetHashCode, implement IComparable. This will optimize the built-in .net indexing, sorting, searching. Many collection "Find" methods take delegates for customized searching. Be sure to read MSDN documentation.
I think this could constitute the core structure. For any given query, staring with initial fetches from these structures should be pretty quick. And yielding custom collections will help too.
There is nothing wrong with a mix of LINQ and "traditional" coding. I expect that in any case you're better off with indexed/sorted tags.
Here's how I'd handle it.
First, use SQLite. It's a single-dll distribution, lightweight, superfast and impressively capable database whose sole purpose is to be used by these types of applications. A database is a far better approach than trying to persist trees to files (the issue with a custom persistence isn't that the idea in itself is bad, but rather than there's a dozen edge cases it'll need to handle that you're not likely to have thought of where a database has them automatically covered).
Second, set up some POCOs for your media and your tags. Something like this:
abstract class Media
{
public string Filename {get;set;}
public virtual ICollection<Tag> Tags {get;set;}
}
public class Image : Media
{
public ImageFormat Format {get;set;}
public int ResX {get;set;}
public int ResY {get;set;} // or whatever
}
public class Video : Media
{
public VideoFormat Format {get;set;}
public int Bitrate {get;set;}
}
public class Tag
{
public string Name {get;set;}
public virtual ICollection<Media> Media {get;set;}
}
This forms the basis for all of your MVVM stuff (you're using MVVM with WPF, right?)
Use Entity Framework for your data access (persistence and querying).
With that, you can do something like this to query your items:
public IEnumerable<Media> SearchByTags(List<Tag> tags) {
var q = from m in _context.Media
join mt in _context.MediaTags on m.ID = mt.ID
join t in tags on mt.Name = tag.Name
select m;
return q;
}
That will covert to a relatively optimized database query and get you a list of applicable media based on your tags that you want to search by. Feed this list back to your presentation (MVVM) layer and build your tree from the results.
(this assumes that you have a table of Media, a table of Tags, and a junction/bridge table of MediaTags - I've left many details out and this is very much aircode, but as a general concept, I think it works just fine).
I create a desktop application using C# + EF 4.0. I'm aware that it's normal to add a custom method to Entity Framework EntityObject using partial classes:
public partial class EntityModel: EntityObject{
public void MyMethod() { ... }
}
But I need to add a custom field to store an information that I don't want to hold in database.
So would it be normal or is there any way to do it?
Sure, just add the property you need like:
public string MyCustomField { get; set; }
But bear in mind that it's stateful for that object so it's not going to persist anywhere unless you do that yourself and it's going to hold a different value for each object, unless of course you made it static, but I would strongly recommend against that.
As long as it's related to the class and doesn't really belong somewhere else, then it's completely normal.
For my homework, I'm implementing a course registration system for a university and I implemented a simple class for Curriculum with list of semesters and other properties like name of the department, total credits etc.
But I'm wondering if I can inherit this class from a Graph Data Structure with Edges and vertices.
Anybody done similar things before?
My current design is something like this:
public class Curriculum
{
public string NameOfDepartment { get; set; }
public List<Semester> Semesters { get; set; }
public bool IsProgramDesigned { get; set; }
public Curriculum()
{
IsProgramDesigned = false;
}
//
public string AddSemester(Semester semester)
{
As an enterprise architect I would absolutely not use a graph structure for this data. This data is a list and nothing more.
For a problem similar to this, the only reason I would ever consider using a graph structure would be to potentially create the relationship of course requirements and prerequisites.
This way you could then use the graph algorithm to determine if it is valid for a student to register for a class by making sure it is a valid addition to the tree. Same for removing classes, it could be validated to make sure you aren't dropping a class and staying enrolled in the lab for the class example.
Now if I was going to actually implement this. I would still have an overall list of classes that have a Key to the vertex in the graph representation. One thing to keep in mind is that graph algorithms are about the biggest heavy hitter you can throw at a database so minimize the amount of work done to pull the graph out is always key. Depending on the size and scope, I would also evaluate if I could store entire graphs in a serialized form or to use a document database for the same reason.
Which in this example would be the most likely route I would take. I would store the entire object of prerequisites co-requisites and so on right inline with my course object. Since the graph is a set it and done event there's no need to do an actual graph traversal and you're better off storing the pre-calculated graph.
Yes you can inherit this class from a Graph data structure. You can make it a subclass of anything you want (except for a sealed class). The question of whether or not it is a wise design is entirely dependant on what you want to do. I assume you know how, so comment if you need an example of how to implement inheritance.
IF you are wanting to write your own graphing algorithms, why not just model it yourself? It would probably be a fun exercise.
I need to display some stats, numbers, and graphs about various game objects on the screen.
(examples: camera position, field of view, frames per second, fill rate, number of objects culled, etc... )
Currently any object which wants to be graphed or displayed implements an interface along these lines:
public interface IGraphable
{
float GraphableValue { get; set; }
}
Then that object can be sent to a graph component to be displayed. This has some obvious drawbacks like not being able to graph 2 different pieces of data which belong to the same class.
What I want is a way to pass a pointer to where the data is located or a pointer to a function which knows how to return the data instead of passing the object to the display component.
I believe that this is what delegates are for but I don't understand how to use them in this context (Actually I don't understand them very well at all). Also, is there another (smarter/better) way to do this?
Thanks!
Why not invert the control like this:
public interface IGraphable
{
void BuildGraphable( IGraph g );
}
interface IGraph {
void AddValue( double value );
}
this is a preferred option in OO anyway as it hides details of the IGraphable implementation. Additionally you can now extend IGraph for added functionality without breaking compatibility.
Depending on how you're doing things, you could possibly use Reflection (attributes on accessors), although that can be relatively confusing at first too. But it's a very useful tool in your arsenal, so it's well worth spending the time on. Here is a great tutorial on how to use them:
http://www.brainbell.com/tutors/C_Sharp/Attributes.htm
But then, learning delegates is also very useful, and that does sound like a good solution. I haven't looked deeply into it, but this tutorial on the same site might be useful:
http://www.brainbell.com/tutors/C_Sharp/Delegates_and_Event_Handlers.htm
I have decided to do the following:
public class GraphComponent
{
private Func<flaot> _function;
public GraphComponent(Func<flaot> function, ...)
{ ... }
}
This allows me to specify how the data is retrieved by writing something like this:
FPSComponent fpsc = new FPSComponent();
GraphComponent fpsg = new GraphComponent(delegate() { return fpsc.ApproximateFPS; }, ...);
What I want is a way to pass a pointer to where the data is located or a pointer to a function which knows how to return the data instead of passing the object to the display component.
If you don't want to add your objects to your graph component BECAUSE
This has some obvious drawbacks like not being able to graph 2 different pieces of data which belong to the same class.
Maybe a list will solve your problem ?
public interface IGraphable
{
List<float> GraphableValues { get; }
}