|
hpjchobbes wrote: but that would mean I would need a table for each field that I would want to search
Consider this the way that DBs do it. That is (at a high level) what gets created when you form an index on a table. That's why you really should not go and create indexes on every attribute of an entity.
One thing you could consider doing is instead of storing the data in an array list of objects in memory, store it in an in memory data-set. That way you can query it using standard SQL queries all you want. Wrap the collection in a class that uses an data set internally to store the data and returns collections of objects to you as the result. That way you can keep your data in a simple search-able format and still get objects to work with latter.
I am sure that someone here could also come up with some cool alternatives using objects and LINQ, but I am not all up on that tech yet 
|
|
|
|
|
I'm just starting to learn programming, so I was trying to keep my implementation simple, but I guess this is a bit more complex problem that I originally thought! I guess for my simple application having a hash table for each field is probably the easiest way to go.
I didn't even think of making my own collection class, but that seems like it might be a good way to go to learn more about databases before I start diving into some of the main databases out there. I'm not to the point where I need to worry about handling large amounts of data, so for now, I'll keep it simple.
Thanks for the information!
|
|
|
|
|
keeping it simple is always good, just build it so that you can extend it latter without having to redo too much of the host application. Always be thinking about encapsulation, even when trying to keep it simpler.
Things have a way of getting away from you and not staying simple for long
|
|
|
|
|
Overriding Equals is only for comparing if objects are the same.
Ignoring indexes, if you need to search a List< Person> then you can do it by hand. Iterate over the list with foreach, and put the results into your result list when the fields match. If you are using a later version of the framework you can pass an anonymous method into the .Find(Predicate< T>) method. This would look like this:
List< Person> results = data.Find(delegate (Person p) { return p.Name == searchName; });
Or in a lambda expression:
List< Person> results = data.Find(p => p.Name == searchName);
If you are just starting programming then worry about the basics first. As for indexing, you should either use a database (Diamond Binding in my sig will make it pretty easy for you) or if you want a pure object solution then you might want to check out a pure object database. db4objects is a very good object database, but can be quite expensive. Generally in the "real world" you would rarely be writing your index code by hand (but it is important to be aware of lookup performance in your data structures).
|
|
|
|
|
Thanks for the response! The .Find(Predicate<t>) function is interesting and I'm going to be looking into that more. All my programming is really for learning purposes, so I tend to try and stay away from solutions that have been built for me as I don't feel that I get a good understanding of what is going on. It's probably not the 'best' method for learning, but it seems to work decent for me.
What I just thought about now, seeing you mention using List<t> instead of ArrayList is how the two differ. I would imagine that ArrayList just boxes everything into an object, where List uses the base type. Would this make it faster to search through a List than an ArrayList as there is no need for un-boxing? I guess there's another topic added to my list of things to research!
Thanks for the information!
|
|
|
|
|
Yeah theres a bit of history there. List< T> is a generic list, which means when you use say List< Foo> you have effectively created a brand new type out of thin air, a List of Foos. Before framework 2, generics didn't exist in the runtime, and ArrayList was a provided and the commonly used IList implementation.
Both are implemented the same under the hood, they both wrap an array which they resize as necessary. For new development you may as well use List< object> over ArrayList, they are functionally identical, but using List< object> makes it very clear that you know the generic class exists - and thus the list is actually full of random crap.
I guess the generic list would remove any unboxing that happens, I had never really looked at it that way (it would definitely help with the semantics of having to do foo = (long)(int)objectWhichIsReallyABoxedInt).
As you learn programming you will hear a lot of people talking (mostly crap) about optimisation. Generally speaking you should look out for the big-O order of things, and obvious problems like doing a bunch of high-latency things in serial. Most things like "avoiding boxing", "avoiding reflection" make little difference to a real world application. In fact I've seen a great many "tips for faster code" that results in identical IL (and thats before JIT optimisation). I use reflection extensively in Entanglar (even in the renderer I'm working on), and the performance of that is more than acceptable.
|
|
|
|
|
|
What if you did something like this:
Create a class called ClientCollection which will have all the clients in some data structure of your choice. Within this class (ClientCollection) have a method called Search, or Find which will take 2 parameters: 1. The property to search by and 2. The value to search for. Within this method create a Dictionary and put all your clients into it. The property to search by will be the Key, and the value will be the Clients. Afterwards, call the Contains method of the Dictionary to search the value passed in.
Of course, this means that if you have many clients putting them into the Dictionary will take time.
I will also do what you suggested above in addition to this but create tables for the field(s) which will be used mostly for searching.
Now you don't have too many tables, but you are also providing the flexibility of searching by any field.
|
|
|
|
|
Hi folks, i'm relatively new to this area of things although i have been using C# for many years. I have been trying to find a starting point for organizing my code for medium sized projects. What i am after is a relatively detailed example of how a software application solution would be organized in Visual Studio. For example if i worked for company CMP and had an application i wished to create named AppX, no doubt i would start with a solution named: CMP.AppX .. and then begin adding projects. I am aware that every situation would be different and would require different projects and namespaces, but i would like an example of how you guys would go about doing it and some reasons for your choices. eg:
CMP.AppX
CMP.AppX.Data
CMP.AppX.UI
CMP.AppX.UI.Desktop
CMP.AppX.UI.Web
CMP.AppX.Webservices
CMP.AppX.UnitTests
CMP.AppX.Reporting
...and how this would be achieved - what was a project and what was subdir in the project folder etc. Thanks in advance.
|
|
|
|
|
We organize our projects normally in this way:
1)
One solution for all projects we are currently developing. Developing with several solutions at once is very cumbersome.
2)
However, if there are components that can be extracted in some sort of library or framework then do it (only feasable for components that can be developed independently for the most part, because of 1)
3)
If our system is built up from different "sub-systems" (sometimes there is a relationship with tiers, but it's possible to have either several sub-systems per tier or viceversa) then we arrange them within solution folders (note that solution folders are virtual folders and that there are no folders in file system for them).
4)
We try to keep the number of projects limited because a large number of projects has a negative effect on build performance. Therefore we wouldn't arrange our project the way you suggest in your post (propably). Keep in mind that assemblies are a deployment unit, nothing else. There is no problem in packing several components into a single assembly, as long as they are deployed together. Requirements on releasing individual components can however be a reason to seperate components into different assemblies.
5) For each project we habe an additional unit test project to seperate the tests from production code. We use a naming rule: for project MySystem.MySubsystem.MyWhatever.dll exists a MySystem.MySubsystem.MyWhatever.Test.dll. This simplifies out NAnt script for building, testing and releasing our software.
6)
Namespaces are hierarchical and should be used in this way. That means that we express abstractions with namespaces. E.g: MySystem.MyComponent contains everything that is used in that component and MySystem.MyComponent.MyImplForCaseX contains the details for a specific extension while the code in the subnamespace can access the content of its parent namespace.
This results in very little access to sibling or child namespaces, thus supporting loose coupling of components.
7)
We use subversion as version control system. With the following structure (this is however really project specific):
root/
trunk/
doc/
source/
libs/ contains all 3rd party dlls our projects reference, built up with svn-externals and real dlls
scripts/ contains all NAnt scripts for building, unit testing and releasing
tools/ tools used for building etc.
releases/
Release 1.0/
[trunk/] only if release is modified (bug fixes)
[releases/] "
That's all I can recall on a Sunday Morning 
-^-^-^-^-^-^-^-
no risk no funk
|
|
|
|
|
|
Hi,
Can anyone suggest how to design application, which support multiple databases (like SQL Server, Oracle) and with minimum change, we can shift database from one to another.
Thanks.
|
|
|
|
|
Colin Angus Mackay has nice series about building DAL that supports multiple databases. Swithing from one database to another is a matter of changing configuration file so you don't need to recompile application. You can find the first part here: What is a DAL? [^]
|
|
|
|
|
With most OR mappers this is a change in the configuration file.
Yes, yes I know, if you have performance optimizations in your code, then it's not that easy 
-^-^-^-^-^-^-^-
no risk no funk
|
|
|
|
|
|
heyitsAtul wrote: Hi,
Can anyone suggest how to design application, which support multiple databases (like SQL Server, Oracle) and with minimum change, we can shift database from one to another.
Thanks.
It can be done in several ways. First of all you need to have an abstraction layer. That layer needs to be a generic layer that matches the interface for both databases. Secondarily, I'll recommend that use a factory. Try to take a look at the following link for inspiration
Connection pool[^]
Hth
--
Jess Nielsen, b.sc.
Security Analyst
http://jessn.blogspot.com/
|
|
|
|
|
heyitsAtul wrote: Hi,
Can anyone suggest how to design application, which support multiple databases (like SQL Server, Oracle) and with minimum change, we can shift database from one to another.
Thanks.
It can be done in several ways. First of all you need to have an abstraction layer. That layer needs to be a generic layer that matches the interface for both databases. Secondly, I'll recommend that use a factory. Try to take a look at the following link for inspiration: Connection pool[^]
HTH
--
Jess Nielsen, b.sc.
Security Analyst
http://jessn.blogspot.com/
modified on Monday, November 8, 2010 3:20 AM
|
|
|
|
|
I come across this often, where to avoid round-trips, simple, and even sometimes complex, validations are implemented in JavaScript on the client. Yesterday I put in a little date range validation, which I should really be done at the business layer. However, with the RIA bubble, the single location of the BL on the server is becoming blurred, and somewhat divided between the client and the server.
This brings me to my question about a model for delivering relevant business logic to the client, but not simply by sending custom JavaScript to implement business logic, but using a fixed JavaScript library that uses a rule base shared with the server. Is there any such concept or product?
Do not believe in anything simply because you have heard it. Do not believe in anything simply because it is spoken and rumored by many. Do not believe in anything because it is found written in your religious books. Do not believe in anything merely on the authority of your teachers and elders. Do not believe in traditions because they have been handed down for many generations. But after observation and analysis, when you find anything that agrees with reason and is conducive to the good and benefit of one and all, then accept it and live up to it. (Siddhartha Gautama - The Buddha), 563-483 B.C.
|
|
|
|
|
It is precisely at this point where I turn from web based stuff to smart client applications 
I know there are many advantages to web based stuff, and RIA tech makes them a bit better, but I really never understood the draw to using these for internal business applications.
[edit] ...especially since we have click-once now. [/edit]
|
|
|
|
|
Good call.
Especially with click-once, and especially for line of business apps when you typically control the client environment.
|
|
|
|
|
Hi,
Lets say I have a class called Person with properties Name, Age, Salary. I create a GUI form to show object of this class so users can do CRUD operations on it. Each property will have a textbox for manipulation. However, if my client adds another field to Person, lets say Phone Number, then I will need to modify the database, the data access layer, the class itself, and finally add another textbox to the GUI for phone number. My question is what pattern can I use to handle a situation like above when clients constantly change properties?
I am thinking of using MVC pattern but that will be for other reasons and will not help my question above.
|
|
|
|
|
CodingYoshi wrote: However, if my client adds another field to Person, lets say Phone Number, then I will need to modify the database
If your users are performing CRUD operations, do you even need a Person class? Why not perform the operations on the database itself?
As far as adding fields to a table, this represents changing the database schema. That's non-trivial; I'm not familiar with a pattern that somehow hides or manages those kinds of changes. They're fundamental and will require all the work you mentioned.
|
|
|
|
|
The way most "modern" (and by this I don't mean code generators) data layers perform the O/R mapping between the business object definitions and the database is by a set of metadata that describes how the fields match up. So when you add a "Favourite Colour" field, you add the field to the database. Then (either manually or automatically depending on your tool) add the field to your business object, and update the mapping. The mapping is then used to handle the actual queries at runtime.
A basic CRUD form could be generated at runtime using a similar set of metadata. Diamond Binding uses attributes on the business objects to say "this field comes from FaveColor" - you could use a similar strategy to decorate your business objects with "default view/controller" attributes - or chuck this mapping in a seperate file (probably a "technically" better solution than having your model aware of the default view/controller). You could end up with the class being decorated with [DefaultEditor(typeof(AutomagicCRUDController), typeof(AutomagicCRUDView)] and your new Colour field having a [FieldEditor(typeof(ColorPicker))].
Unfortunately I think you'll find that your clients will end up wanting minor changes to every form you show them, and you'll end up with something pretty close to doing it manually anyway. So my pattern tip is "Hire a load of graduates and get them used to the pain of dealing with clients"
|
|
|
|
|
Great. Thanks for the explanation and honesty.
I just thought I might be doing something wrong because a good design should not cause a ripple effect--I guess that is just "theoretically speaking".
|
|
|
|
|
The real problem here is that most clients think that a simple new field is something trivial to add.
But it's not because:
- How should it be presented in the UI (UI Layer)
- Do the validation rules checking the consistency change (Logic Layer)
- compatibility with old data (Logic Layer, DB Layer)
- Persistency impact (behavior of database, growth, indices, replication, transfer to data warehouse) (DB Layer)
And propably some more...
-^-^-^-^-^-^-^-
no risk no funk
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
