|
Not if the one you love is 10,000 miles.
This statement was never false.
|
|
|
|
|
My app have a main form (mdi contaier) with a treeview menu. Interacting with the treeview, for example clicking the project node, opens up a new project form (mdi child), clicking the status node opens up a new status form (mdi child), etc. I want to use a MVC pattern for the gui part and have some questions regarding this (first time using MVC).
* Is it sound to have one controller for each form, ie maincontroller, projectcontroller, etc?
* As it is now the maincontroller instantiates (opens) the other forms and their controllers and passes along a reference to the mainform (some of the childforms need to update the treeview menu). Is there a better way to do this?
/thanks
|
|
|
|
|
I would be very surprised if you could break a project down to a 1-1 mapping between controller and view. This was the type of model that was exposed as Document-View and was widely seen as having problems. It is more likely that your controller will have several views.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
So your saying that I should try keep it down to only one controller? or is there another approach? /thx
|
|
|
|
|
No - I'm saying keep it down to 1 controller per model. You can have multiple views per controller/model.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
ok, yes that makes sense 
|
|
|
|
|
I recently spotted this post, included in the Code Project Insider newsletter:
http://www.codeproject.com/lounge.asp?msg=1992197#xx1992197xx[^]
I got me thinking, we are currently building an app that makes use of tab-like panels, similar to VS2005. Where each panel may deal with completely different aspects. It has a great feel and allows for quite a bit of customization (particularly layout) of the user-interface by the user. But what I hate is that now all your code goes into 1 file/form. (Not even using Regions helps!)
What do you think is the best approach to "compartmentalize" your code in a "per panel" manner as such? I have started using partial classes and this seems to work OK. Any other ideas or am I the only one that hates thousands of lines of code in the same file/form??
Francois
(Sorry if this is in the wrong forum)
|
|
|
|
|
Why does all your code go into one form? Surely it should be divided according to purpose. The only code that should go into one form is the code to manage the tabs. Each tab then uses code from a component built for the content of that tab.
|
|
|
|
|
Thank you for responding, it is a valid question. Let me clarify.
The form does use classes and other components to do the "work". In make case however you have multiple tab-panels not of the same instance as such each tab-panel has a unique set of controls (buttons, grids, etc). I am refering to the many even handlers for each of these controls; purly UI code. This, at least for me, becomes "too much" code on one form.
Although as I am busy typing this I think think I just figured out what you may be refering to - coding each tab as a component, a custom control as such and then just addint the control to the tab? It makes sense *feeling stupid* - it this what you were saying?
Francois
|
|
|
|
|
Yes, that's exactly what I am saying. Don't feel stupid, it's coming to realisations like this in a real world scenario that teach more than just the written word can ever hope to.
|
|
|
|
|
Makes perfect sense! Can't believe I didn't think of that. Oh well
Would still be interesting if anyone else has another approach. There is often more ways then one to skin a cat
|
|
|
|
|
I've been trying to figure out what would generaly be a better course of action regarding Business objects. I have a few options, and i was just wondering what methods other people use, and in what situations.
1) A Data Object with a support object for manipulating data.
2) A Data Object with integrated data manipulation.
3) A Data object with a supporting data manipulation object that can be injected into the Data Object and used to manipulate Data via proxied functions. (A kind of hybrid, almost like injecting a DataAdapter.)
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
But this isn't always sound advice when someone already has the requirement to build their app to be compatible with both Oracle and MS-SQL.
Rarely do they have the option of changing storage mechanisms. Alot of the times clients already have thousands invested in their database, and just want an app to couple with existing apps and data.
How would you treat a scenario where you had to be able to work with a set of objects that could either be loaded from an Oracle or MS-SQL database, or be loaded from an application server?
You don't have the option of using your page based db either. You can use PE but it has to be able to talk to an app server over tcp/ip, Oracle, and MS-SQL?
I appreciate what you are trying to convey by exposing people to these simpler models, but when someone is asking for advice for a current dilemma, I think it does a disservice to them and doesn't really help.
This statement was never false.
|
|
|
|
|
|
The Grand Negus wrote:
If something is crappy, it should be opposed. Passionately. No man has to work on junk; he chooses to.
I completely agree with you on that.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Ahh... but the product is to be available to people independent of their storage choice. Not to force them in any direction. Say a large company like Oh... maybe FedEx, wanted to purchase our product. But they have 100s of thousands invested in their systems. Database and otherwise.
It would be in our best interest to support as many storage mechanisms as possible to ensure sales.
What you are proposing is not very realistic. Expecting customers to invest more money into third party software when they already have software of their own, isn't reasonable. You are asking them to throw away money. I don't know of any company that is willing to do that.
This statement was never false.
|
|
|
|
|
I would recommend keeping the object neutral with regard to source. So seperate out the population mechanism such that it can come from multiple datasources if you have that requirement. I wouldn't couple it with a dataset for instance. For instance we have to support loading from an app server, oracle, or mssql.
As far as whether it should be flyweight or not really has more to do with your application.
Even for the flyweight pattern I embed some transformations. Like say dates, int verses string, etc. For bulk operations I usually put together a helper class that knows how to use them. Which would usually be tied to some other mechanism like a database, or app server.
Is that kinda what you were looking for? I guess it depends on what you mean by data manipulation.
This statement was never false.
|
|
|
|
|
Hi Chris,
I've never really liked using datasets as a whole, but i do find the Tables and Adapters immensley useful stand alone (Although there is exactly zero chance of a DB change).
By Manipulation, i mean the functions that wrap execution of the SQL.
As a concrete example, i've tried it a few ways, but i'll go over them briefly and see if that clarifies anything.
1) An Account data object that contains just the fields, and an account manager object that can handle inserting, updating, enabling / disabling etc.
2) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc.
3) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc, with a support class which has the same functions (like example 1) and is required inside the data object for the data object's functions to work. Basicaly the functions proxy to the internal objects method calls.
I've tried all of them, and unfortunately, its left a bit of a mess in some of my code as i couldn't make up my mind what was the best way to go about it. I lean towards option 1, but think that 3 has some potential if done right.
T
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
I would opt for number 1.
It leaves the data objects light weight in case you need to marshall them, or bind them to a web page etc. And in the case where maybe the database itself won't change, the schema might, and if you need to handle that case, then the places where the data objects are bound to controls etc, nothing has to change. You just change it in the data layer in the helper class.
[edit]
I usually use DataReaders and populate a custom collection instead of DataTables and DataAdapters. But the DataTable is nice if you need a filtered view in addition to the standard one.
[/edit]
This statement was never false.
|
|
|
|
|
Hi Chris,
Thanks for that, i think that's pretty much what i ended doing, using the DataRow as a data object, and the DataAdapter as the actual SQL wrapper.
I would be happy to use a DataReader, but find that i'd have to write reems of code to support it, and generate the queries and parameters etc. I'm guessing you use some kind of code generator for generating your parameterised SQL / Stored Procs? Did you write your own or go 3rd party?
If you wrote your own, How do you enforce field constraints (i.e. max string length 40) in the data object? Similar to the way a data row does.
If you went with the 3rd party route, what would you recommend?
Cheers Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Alot of coding.
My system is on the mobile device. PocketPC. So, for my application I also have to generate the database. So I use a set of table descriptions that define the database to populate the business objects with. I use a table description to generate the select sql then populate the businss object from a reader into a generic collection. Validation of data is done at the form level. Since most of my processing derives from the user and the UI. Type constraints haven't really affected me much.. yet. I don't enforce anything in the data object. Its all either in the UI or in the DB.
This statement was never false.
|
|
|
|
|
I suppose what drives me nuts is when i forget enforcing on the front end, that gets dumped to an BO, and then on inserting into the DB, the data is out of range and the app falls over. Makes it a mission to figure out where it went wrong, which would be when the value was set.
They use a truncation method where i am atm, which drives me up the wall because there's NO length checking anywhere.
><
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
I have to develop specifications for a variety of integration architectures - mainly services based and using Message Queues, BizTalk and web services.
Previously, I was lucky enough to just do the dev work, if the specs were crappy, any number of e-mails would solve the problem. On the current project, specs have to be perfect.
Anyone know where I can get hold of the best, silver bullet template or a sample of an awesome spec? I am less interested in the boiler plate (doc distr. signoff lists etc).
Cheers
|
|
|
|
|
|
 Did you ... wait, nevermind.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
