More C# help... JTable equivalent this time

Deenem said:
That sounds like a maintenance nightmare. You've created a direct dependency between your database and your user interface, change one and you have to go change the other as well.

When I design systems, I start by designing the data model to suit the business domain (not the user interface). If you design the data model to match the UI, then you've created a dependency between the two.

Step 1 for me is to design the data model. Once I've got the data model to accurately represent the business domain, then I give it to the programmer and let him go wild with it. He can design the UI with as many bells and whistles as he wants, but he has to work to the data model that he has been given.

Of course there's going to be redundancy in any given UI representation of the data, but data model will always be an accurate representation of the business domain even though the UI may choose not to display all the data it's been given.

That gives you the flexibility to design various UI's using different delivery platforms without having to redesign the data model for each platform. So there is never a dependency between the UI and the data.
Click to expand...

Well, strokes and folks, you know? In my case, the data model that is returned to the "code" is derived from a single or set of data views. By using dynamic SQL in all my stored procedures (sp_ExecuteSql), I can filter the results of my views by just about any parameter(s) passed through to the SP. 99% of the times the SP returns a simple "select * from vw_VIEWNAME where 1=1" with a bunch of extra where-clauses, depending on which parameters passed through are NOT NULL. The fields that are returned are then just changed in the view.

The philosophy at our company is to do as much as possible on the database side and leave the code to facilitate interaction between the database and the UI. Our "business layer" consists of objects representing the necessary business rules and entities, which are then used in the presentation tier to facilitate user interaction with the data.
 
Right, after extensively researching MVC during yesterday and this morning, it seems that I've been sort of implementing it all along. I very seldom use web-forms to "design" the layout of the page, but rather revert to templates to create views of my data model. I also have libraries of code to facilitate as a sort of controller in the whole process.

Well, in my next project I will certainly be conforming to a more structured MVC approach. MVC FTW! :D
 
MVC is bad and improper !




/runs for the safe hills :D
 
FarligOpptreden said:
Well, strokes and folks, you know? In my case, the data model that is returned to the "code" is derived from a single or set of data views. By using dynamic SQL in all my stored procedures (sp_ExecuteSql), I can filter the results of my views by just about any parameter(s) passed through to the SP. 99% of the times the SP returns a simple "select * from vw_VIEWNAME where 1=1" with a bunch of extra where-clauses, depending on which parameters passed through are NOT NULL. The fields that are returned are then just changed in the view.
Click to expand...

OK, except now you're creating a dependency between your data model and your database.

Step 1 for me was creating a data model to accurately model the business domain. At the end of the process I'm going to have a data model that can be used to represent all the information required in the business domain.

Now we get to step 2, which is to create a data layer to source all of the data and populate it to the data model to create datasets.

That data might come from legacy systems, it might come from third-party providers, it might come from an external vendor service layer. Many systems I've worked on somehow involved the Excel spreadsheet on the financial directors laptop :) Again, there's no dependency between the data model and the data source. The data source can be changed without having to resdesign the data model.

Inevitably you end up creating a database to store the data you don't already have, but you shouldn't just copy the data model design into a new database. The data model was designed with the business domain in mind, not with an efficient database design in mind.

Step 3 is to decide what technology you want to use for the User Interface. Each month there's a new flavour of the month as far as presentation layers go, but it doesn't matter, because we've got a solid data model that covers the whole business domain.

We have a data layer to to source the data and populate it to the data model to create datasets. All we need to do now is pass the data sets to the presentaton layer and let it display the data in whatever way it wishes to.

If a new presentation technology comes along (Silverlight anyone?) we just pass the existing data to the new presentation layer and it has to display it. No change to the data model, no change to the data layer, and no dependecies between the layers. Easy!
 
Well, like I said, in my next big project I'm going to opt for ASP.NET MVC to see what it can offer. I've got some solid ideas on what I want to implement to achieve full SoC, but that project is still a good 6 months away. You learn something new every day...
 
Deadlines on the 7th of Jan? Let me guess, the project was due to go live on 30th November? :)
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X