Best Practices !

Well i just want this thing to be clear to me. Were introduced by the OOP approach and the XP Approach. Now i'll give an example that we made for. We are making a large database system and we need to use the XP and OOP approach. So our team head decided that all procedure, connections string, querys must done in a different classes. One for connection string, one for querys, and so on. With that by just calling their methods it would be easier to debug and add new features.

At instance if i have the query method in the query class to be able to execute the query all i just to do is call the connectionstring in the other class and this query method in query class can be now executable. And all this query will be just call in the Application.

Is this good or recommendable and can be understand easier ?

Or its better that the connectionstring and query can be combined together in one class with that it could be a lesser time and lesser space for coding ?

Well the descriptions I've read of XP sound more like a sort of Twit Olympics of coding, but so far you haven't described anything that sounds very "XP" to me.

What I do see sounds like the sort of "drunk on objects" philosophy you see in Java shops. It smells a bit of Cargo Cult OOP: "Somebody said use classes. What are classes for? I know, we'll put all of our literals and procedural code into a flotilla of classes! Then we'll have OOP. World saved."


Ecapsulation and reuse are the best things you get from classes. But I can't imagine what advantage ensues from creating a class to return a connection string, another to return a SQL statement, another to contain a blob of procedural logic, etc. ad nauseum.


I've been known to put extensive SQL statements into resources as a way of avoiding clunky inline String literals and having to escape my quotes all over the place. This is always a pain though, since it remotes the SQL and upon later reading the code isn't as clear when the SQL is off somewhere else.

One of the fabulous features in VB.Net 2008 is supposed to be inline XML. That seems to run 180 degrees away from what you're proposing.


If ADO (or ADO.Net) did not already exist you might have a case for creating some sort of data access object model. But what is the point of layering a private one on top of the one you already have? And one that will probably require tweaking and maintenance for years to come? One that just increases the learning curve for any new team members added in the future? One you'll have to write and debug in the first place?


At some point you just have to start solving the problem you've been assigned. While creating new ways to Jump the Shark might seem less boring you'll probably live to regret it.

We see this all too often. Fitting a task around a tool rather than using a tool for a task. Someone else had once posted questioning why this was happening, and I wrote my thoughts on it. Have a read http://www.vbforums.com/showpost.php...0&postcount=11

I think you're talking about the "what if" syndrome, or officially known as Cargo Cult.

For one, why should the queries be done in a class, can they not be moved to a stored procedure? What is it about your connection strings that's going to change in the future? I don't know how experienced you are or how much say you have in the matter, but I'd at least ask questions as to why a certain way has been chosen.

Is this correct ?, use an OOP approach rather than an structure approach, because in OOP its easier to find a bug and make an updation or adding a new features rather than structure ?

Ok thanks to your replies. Now when exactly a code must put on a class or class library, and what exactly must put on a class or class library. Is it a method, database connection, procedures what ?

sql belongs in stored procedures, ado.net is your data layer, classes are good to connect the interface to the object, the object maps (connects) to a data entity.

any more than that requires a psychiatrist be on the team.

granted it's simplistic but it gets the job done.

Quote:

---

Is this correct ?, use an OOP approach rather than an structure approach, because in OOP its easier to find a bug and make an updation or adding a new features rather than structure ?

---

Coding with OOP is probably just as likly to be more awkward to find bugs in rather than procedural programming. Of all it's great merits, debugging probably wouldn't be on my top 1000 reasons to use OOP at all.

Quote:

---

Ok thanks to your replies. Now when exactly a code must put on a class or class library, and what exactly must put on a class or class library. Is it a method, database connection, procedures what ?

---

I'd suggest picking up the "class design handbook" by Wrox which describes when to add a class, and to review the online MSDN documentation with that book on when to use classes over interfaces.

Quote:

---

sql belongs in stored procedures

---

If you have this option yes, however if you're solution is targeting multiple database types, or a database which doesn't have SP's this won't be an option. Use these where you can when viable.

Quote:

---

Well the descriptions I've read of XP sound more like a sort of Twit Olympics of coding, but so far you haven't described anything that sounds very "XP" to me.

---

Unit testing and test harness programs and more communication will always be useful in programming, however any style which ditches documentation shouldn't be looked at with complete seriousness and faith, documentation should be required at all stages. full stop. Agile is more useful in (some) testing cases, XP is ok, but as a base and documentation should always be required.

Connection strings should be contained outside of the database (D'uh) and from being hardcoded - whether in a class, module or anything of the sort. Config files are provided for such tasks.

This all boils down to getting a decent architect who can define all these answers and practices based upon the problem in hand. I believe it sounds like you could do with employing one or a new one.

Quote:

---

Originally Posted by Loraine

Is this correct ?, use an OOP approach rather than an structure approach, because in OOP its easier to find a bug and make an updation or adding a new features rather than structure ?

---

It is subjective. I would tend to say the opposite: that (class-based, such as in .NET and Java) OOD promotes rigid design and forces the programmer to spend more time on architecture than actual functionality. Granted, this can be beneficial initially, but becomes a hindrance in the long run.

Used appropriately, OOD does not in itself make debugging either easier or harder. What it does do is lend itself very well to over-abstraction, which does make debugging considerably more difficult.

We have a combined connection string and error writing function that is written into a class and compiled into a DLL that all developers use.

But, we are also all writing code against the same database.

Quote:

---

Originally Posted by alex_read

...This all boils down to getting a decent architect who can define all these answers and practices based upon the problem in hand

---

I cannot agree more...

You architect your application based around the environment and the purposes you intend to serve. That's like architecting anything - not just software.

We were lucky enough to start a 5+ year "fully funded by the customer" development project to architect from the ground up an enterprise environment with MS SQL server a guarantee.

With that we did a 100% "use stored procedure" environment. And pushed our BL into the SPROCS. All SPROCS have a naming convention that binds them to the application automatically. All SPROCS have the same 9 or so parameters at the top to allow for state-management changes to the UI - all controlled from the SPROCS.

By architecting this way we have created a shop where us programmers spend nearly all our time doing business logic changes in T-SQL to SPROCS. We are incredibly efficient in delivering enhancements with this - and the customers can see this. And we are using T-SQL - a standard language known by many programmers. Not like SAP where you have to learn ABAP to work the application...

So after coming from 20 years in my industry (from the mainframe world) and knowing what our customers require and how to run a shop of developers to deliver such we created a solution that served that purpose.

Quote:

---

We have a combined connection string and error writing function that is written into a class and compiled into a DLL that all developers use.

But, we are also all writing code against the same database.

---

Sir can you show me a sample with that ?

Quote:

---

Coding with OOP is probably just as likly to be more awkward to find bugs in rather than procedural programming. Of all it's great merits, debugging probably wouldn't be on my top 1000 reasons to use OOP at all.

---

So you are saying that using OOP will make it difficult to debug find an error. And its better to use a procedural approach?

Quote:

---

Originally Posted by Loraine

Sir can you show me a sample with that ?

---

Sure. I can make a generic project out of what we use, but it is in VB.NET - are you using that or VB6?

@mandhak - "what if" syndrome - a very dangerous thing indeed. I was recently part of a project where we kept being paralyzed by a number of "what if" ... the meetings went on endlessly. Then the guy from Testing noted "What if a monkey with a 2x4 shot out my arse." ... The problem is that sometimes the "what ifs" are valid (what if the system we are communicating with takes a dumper?) ... but can go to an extreeme( what if the user puts a ' in this field?) ..

When properly implemented OOP can be a good thing. When done under the right conditions XP works too.... In our shop, XP doesn't work worth the paper it was printed on. Sounded like a good idea, just didn't pan out that way. So we did it our way, making up the processes as we went along, and that seemed to work just fine.

The problem is that there are so many design patterns and development styles that people think is the next coming, and they extol their virtues as being the ultimate. And people then come along and see the virtues of the process and think it's the Holy Grail. Well, the Holy Grail of Development Processes doesn't exist. The ultimate method is the one that works. Just like the ultimate programing language is the one that works for the needs at hand.

-tg

@Hack - Thank you sir, yes im using VB.Net. Im going to check how you done it in a class and what specific procedures stored in a class.