I'm a total amateur writing a small App to track to changes in folders. I imagine I'll be keeping information about the directories to watch in one datatable bound to a gridview, when the user clicks a button, the program will create FileSystemWatchers to keep an eye on the directories and they will send their event messages to another datatable bound to another gridview. Where in the wide wide world of OOP should I be declaring, initiating, and manipulating the Datatables? The main form, inside main, in a class, or should I "give up" and use Visual Studio to automagically create a DataSet and stick two tables in it?
Well horses for courses. For a little utility app you would probably be better off using the VS "Visual/RAD" style of programming. Eg drag and drop tables etc on to the form, like most of the tutorials show.
Strictly speaking, and for a larger app, a more correct way would be to make a separate assembly(.dll) that handles data access and you call the classes within that assembly from the main form. This concept goes under a number of terms, but effectively you want to separate your concerns. In other words, let the UI handle UI interactions, have a separate assembly/project/whatever that handles database interactivity, and another separate assembly/project/whatever that handles business logic etc.
That last couple of sentences can mean different things to different people, and there is no 100% correct way to do things.
Some articles that may help:
link text
link text
link text
I agree with KiwiBastard: you get quite a bit of benefit from using the VS tools to generate a typed DataSet.
That just generates classes, though. You still have to manage an instance of the DataSet. For a very simple app, where I haven't factored UI and business logic into different classes, I'd do that in the Form. For an app of any complexity, it's part of the business logic class.
Something that will probably save you a lot of trouble: data binding is good, ADO is good, but certain kinds of ADO code (in particular event handlers on the DataTable) do not play well with data binding. If you're using BindingSources (and, really, you should be), it's generally a good idea to suspend binding whenever you're manipulating the DataSet's objects programmatically (like, when you're adding and deleting rows). The cost of suspending and resuming binding is very small, and it eliminates an entire class of problems that are extremely hard to diagnose.
Related
I looking simplest way to implement master detail winforms app (using mainly data grid view)
It should interact with database, handling database exceptions (eg unique index violation) and work in multi user environment (concurrent updates etc)
I know how to do that with data set and relation between tables, not sure what is best approach if this has to work with database
Few years ago I did similar app base on business objects and stored procedures but I believe this can be done easier this days.
Appreciate if someone can share general ideas or share some links to webpages discribing that in detail
A DataSet combined with a BindingSource could be, what you are looking for.
For a simple master/detail view it provides everything you need.
Connection management.
Certain degree of error handling.
Binding every kind of control to your data
In simple cases, like yours, almost everything can be done in Visual Studio GUI
Data-navigation controls
BindingSource
BindingNavigator
I'm building a C# desktop application for the management of HR decisions (e.g., the termination of a contract, the approval of a requested leave,...).
These decisions are to yield several Office documents (e.g., contracts, lists...).
The end user must be able to:
define new types of decisions,
define the content of the corresponding documents (by which i mean, define the boilerplate text, and the positions where data from a field needs to be inserted),
change the content of the documents for a given DecisionType.
The design i have in mind:
The class Decision has a field decisionType.
The class DecisionType has a property FieldsList, which lists the names of all fields the DecisionType has, and their datatypes.
When the end user clicks a button to enter a new decision, the application generates a user form (i suppose WPF is more suitable for this then WinForms is, although i've never used it) that allows creation of a new decision of the chosen DecisionType. This form contains only those controls needed for the fields a decision of that type uses. The application adds all required databinding.
The end user manages the content of the documents for each DecisionType:
the boiler plate text,
the positions where persisted data need to be inserted.
This is saved as a string, in which the position where data from a field needs to be inserted, is indicated by a code (e.g., "/[bd]" for the field BeginDate).
The database uses a single table for all decisions (although most DecisionTypes won't use all fields).
But... maybe you people know a better way?
Well, it seems like only one table won't help. I mean, you got to create a Person class besides the Decision one. Each Person may have one or many Decision and a Decision should be editable by another people.
Let's get an example:
John made a decision and save it as Decision A
Paul agrees with Decision A but would like to have some other input at it.
I guess you can see where this is going.
Regarding technologies, I would definitely use WPF - although its learning curve is steeper, once you got it you can do anything, practically. WPF also suggest a MVVM approach, which will greatly improve your time with Data Binding.
As for Database, I recommend Entityframework. Its Code First scheme is very easy to understand and you'll find a lot of info around.
Some useful links:
www.wpftutorial.net - Very basic, introductory WPF info, great for starters
CodeProject - MVVM Example for Beginners
Julie Lerman's Entity Framework website - She's one of the best at it!
Don't give up and good luck.
I am working on a .NET application and we are storing our UI elements in database(UI interface metadata). Can someone guide me what scenarios I need to consider in terms of Maintenance, Performance, Deployment, upgrades of application while designing?
What are trade offs in storing UI metadata in XML and UI metadata in database?
I think it would help to define some examples of the metadata you are storing.
Some things I think of when you say metadata for the UI:
Values of dropdowns. A list of states as an example.
Dynamically created UI elements. Can add a textbox to a form via the database.
Colors, fonts, alignments, etc. "A red button aligned to the left"
Each has pros and cons to being in the database.
From experience, when putting too much UI information in the database, the application becomes very hard to reason about. You'll render the UI and it won't look right. Then you spend half the day going through your code and your database trying to figure out why. You'll flip a few bits in the database and render the UI again and wonder why it didn't work.
Also there is a ton of boilerplate code generated when storing too much information about the UI in the database.
Some questions to answer for each UI element:
"Would this be easier to maintain if it was just hard coded in the UI?" It's easier to change HTML in an HTML editor instead of via the database.
"Will this UI element need to change a lot over time?" Unless some user needs to update/change/modify that element, leave it hard coded.
"Do I really want a ton of database tables for UI elements?" It can become a nightmare to maintain. For example, a survey of questions and answers might produce 5-10 tables.
I'd recommend trying to keep the UI elements as much as possible in the application. Only when absolutely necessary should you write them to the database.
I'm currently developing an application using ASP.NET MVC, and now I need to create an interface (web page) that will allow the users to pick and choose from a set of different objecs, the ones they'd like to use as the building blocks for constructing a more complex object.
My question is supposed to be generic, but to provide the actual example, let's say the application that will allow users to design pieces of furniture, like wardrobes, kitchen cabinets, etc. So, I've created C# classes representing the basic building blocks of furniture design, like basic shapes (pieces of wood that added together form a box, etc), doors, doorknobs, drawers, etc. Each of these classes have some common properties (width, height, length) and some specific properties, but all descend from a basic class called FurnitureItem, so there are ways for them to be 'connected' together, and interchanged. For instance, there are different types of doors that can be used in a wardrobe... like SimpleDoor, SlidingDoor, and so on. The user designing the furniture would have to choose wich type of Door object to apply to the current furniture. Also, there are other items, like dividing panels, shelves, drawers, etc. The resulting model of course would be a complete customized modularly designed wardrobe or kitchen cabinet, for example.
The problem is that while I can easily instantiate all the objects that I need and connect them together using C#, forming a complete furniture item, I need to provide a way for users to do it using a web interface. That means, they would probably have a toolbox or toolbar of some sort, and select (maybe drag and drop) items to a design panel, in the web interface... so, while in the browser I cannot have my C# class implementation... and if I post the selected item to the server (either a form post or using ajax), i need to reconstruct the whole collection of objects that were already previously chosen by the user, so I can fit the newly added item... and calculate it's dimensions, etc. and then finaly return the complete modified set of objects...
I'm trying to think of different ways of caching, or persisting theses objects while the user is still designing (adding and deleting items), since there may be many roundtrips to the server, because the proper calculation of dimentions (width, height, etc of contained objects) is done at the server by methods of my C# classes. It would be nice maybe to store objects for the currrent furniture being designed in a session object or cache object per user... even then I need to be able to provide some type of ID to the object being added and the one being added to, in a parent owner kind of way, so I can identify properly the object instance back in the server where the new instance will be connected to.
I know it's somehow confusing... but I hope this gives one idea of the problem I'm facing... In other words, I need to keep a set of interconnected objects in the server because they are responsible for calculations and applying some constraints, while allowing the users to manipulate each of these objects and how they are connected, adding and deleting them, through a web interface. So at the end, the whole thing can be persisted in a database. Idealy I want even to give user a visual representation or feedback, so they can see what they are designing as they go along...
Finally, the question is more so as to what approach should I take to this problem. Are C# classes enough in the server (encapsulating calculation and maybe generating each one it's own graphical representation back to the client)? Will I need to create similar classes in javascript to allow a more slick user experience? Will it be easier if I manage to keep the objects alive in a session or cache object between requests? Or should I just instantiate all objects that form the whole furniture again on each user interaction (for calculation)? In that case, I would have to post all the objects and all the already customized properties every time?
Any thoughts or ideas on how to best approach this problem are greatly appreciated...
Thanks!
From the way you've described it, here is what I'm envisioning:
It sounds like you do want a slick looking UI so yes, you'll want to divide your logic into two sets; a client-side set for building and a server-side set for validation. I would get heavy on the javascript so that the user can happily build their widget disconnected, and then validate everything once it's posted to the server.
Saving to a session opens a whole can of webfarm worms. If these widgets can be recreated in less than a minute (once they've decided what they like), I would avoid saving partials all together. If it's absolutely necessary though, I would save them to the database.
If the number of objects to construct a widget is reasonable, it could all come down at once. But if there are hundreds of types of 'doors' you're going to want to consider asynchronous calls to load them, with possible paging/sorting.
I'm confused about your last part about instantiating/posting all objects that form the whole furniture. This shouldn't be necessary. I imagine the user would do his construction on his client, and then pass up a single widget object to the server for validation.
That's what I'm thinking anyway... by the way, hello StackOverflow, this is my first post.
You might want to take a look at Backbone.js for this kind of project. It allows you to create client-side models, collections, views and controllers that would be well suited to your problem domain. It includes built in Ajax code for loading/saving those models/collections to/from the server.
As far as storing objects before the complete object is sent to the server, you could utilize localStorage, and store your object data as a JSON string.
I'm finding myself with a bit of anarchitectural problem: I'm working on a smallish project that, among other things, involves data entry and persistance, with a DAL using a webservice with a custom JSON protocol. So far, so good, and it would be a relatively simple matter slapping together some quick&dirty DataTable + DataGrid code and be done with it.
This is a learning project, however, and I'm trying to figure out how to do a somewhat cleaner design, specifically MVVM with a WPF gui, using the Caliburn.Micro framework. The server part is fixed, but I'm doing the entire client part, including the DAL.
With the DG+DT combo, it's pretty easy doing a bunch of edits in the DG, and when user commits simply iterate the Rows, checking the RowState property and firing create/update/delete DAL methods as necessary. DataTable doesn't seem very MVVM databinding-friendly, though, and the ViewModels involved shouldn't care what kind of UI control they're being used with... given that persistance is done through a webservice, requiring batch commit of modifications seems reasonable enough, though.
So I'm pondering what my design options are.
As I understand it, the DAL should deal with model-layer objects (I don't think it's necessary to introduce DTOs for this project), and these will be wrapped in ViewModels before being databound in editor ViewModels.
The best idea I've been able to come up with so far is to do a clone of the items-to-be-edited collection when firing up an editor ViewModel, then on commit checking the databound collection against the copy - that'll let me detect new/modified/deleted objects, but seems somewhat tedious.
I've also toyed with the idea of keeping IsModified and IsNewlyCreated properties (I guess those would go in the ViewModel?) - keeping track of deleted items could probably be handled by keeping the editable items in an ObservableCollection, handling the CollectionChanged event, and adding deleted items to a separate list?
As you can see, I'm pretty unsure how to handle this, and any suggestions would be greatly appreciated :)
First of all
1- Don't do any changes untill you reached a point where you can't live without code changes.
2- As you already said that , you are creating a learning project and you want more modular application so my thoughts would be revolving around how to make my application more modular first before going deep into implementational details.
3- Have you considered using Prism + MVVM framework?
4- I would still suggest that in your ViewModel , you can still use DataTable to bind the data to the grids and byusing DataTable.GetChanges() method will give you all the changes in the table so you don't ever need to maintain boolean varaibles like IsNew or IsModified.
5- If you are not convinced using DataTable yet than use ObservrableCollection to bind data to the grid. ObservrableCollection does not notify indivisual item changed , it will only notify when item are added or removed.