|
I've been programming with .NET for half a year now.
It's all pretty great and fairly easy, but I can't help to think that some classes/components were made to have an extra shell around them.
Take the whole process of connecting and reading/writing data from and to a database.
At the very least we need a Connection object and a Command object and dependent on what you want to do you need a DataReader, DataAdapter, Parameters, CommandBuilders, etc... It seems to me that constantly creating all those objects, configuring them etc. seems like a lot of work. So it would seem to me that it is easier to create a class that requires some parameters in its constructor, has some methods and functions that manage all the just mentioned classes and simply gives a resultset using something like DBClass.Execute.
Basically it would then look something like:
Dim myClass as New DBClass(aString, commandType, connectionString)
myClass.AddParam(name, DBType.Int, value)
Dim result = myClass.Execute ' Or myClass.ExecuteASync!
' Do stuff with the result.
Another example of stuff that just screams for an extra layer around it is the whole printing process.
Have the PrintDialog, PrintPreviewDialog, PageSetupDialog, PrintDocument, maybe PrinterSettings, the whole event thing...
I just want to say:
Dim p as New PrintClass(document)
p.Print ' Or, once again, p.PrintASync! ;)
At this point, is anyone really disagreeing with me?
Or do you really agree and know some other stuff that just calls to be put away in a programmer friendly class? 
It's an OO world.
|
|
|
|
|
There are many Database access frameworks. Look at Microsoft Data Access Library, or Entity Framework, or nHiberate, and many others.
You may need, or think you need, a wrapper for the printer functions in your application, but other many not.
IMO, six months of experience is not enough for you fully understand the concepts of OOD and be able to make such generalizations.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I don't really think my six months of experience have anything to do with it... I know people who have been in the business for over twenty years and who really just don't get it. I'm also not saying I need a layer around the database access or printing because I don't understand what's happening, I'm saying I could use one because it saves a lot of work (and it's fun making them). Visual Studio's 'TableAdapter' and Entity Framework are good examples of that (in that aspect Microsoft already did the work for me  ). Although there's probably many people out there that prefer their own database access layer above any other layer out there. Or people that wrap some exotic .NET functionality in a new easy to use class.
So I'm just asking what are you wrapping and why
It's an OO world.
|
|
|
|
|
Naerling wrote: I don't really think my six months of experience have anything to do with it
I think your statements highlight your youthful inexperience quite well. Please, continue.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I think that if six months of experience is the only thing you read in my question that says more about you than me...
Just give me the answer you would have given me if I had not mentioned my 'level of experience'.
It's an OO world.
|
|
|
|
|
Naerling wrote: So I'm just asking what are you wrapping and why
Database layers - always.
Communication layers - always
Specification layers - always (where a specification might differ from a communication layer in that say a service provider might provider a description of IP interactions to get an XML result. First is communication, second is dealing with a data.)
I always have disparate code for the following as well although whether it is a 'layer' or library is not as clear.
- Logging
- Different types of business logic
- Security utilities
- Unit testing (to emphasize that the unit testing code is contained separately.)
- Executable wrappers (server, command line, etc whatever makes it into a specific executable is kept separate from rest of business logic.)
Goal of doing this is to make unit testing easier and to make maintenance, in terms of the layer, easier. This should occur because making it in to a layer should reduce coupling thust changes are less likely to ripple.
Naerling wrote: Or people that wrap some exotic .NET functionality in a new easy to use class.
Or even day to day functionality but which is implemented in a completely weird way, such as the email client code.
|
|
|
|
|
Naerling wrote: I can't help to think that some classes/components were made to have an extra shell around them.
Most of use have an assembly (or multiple) that contain utility-routines. Great for building prototypes, where you can generalize away and focus on the functionality.
Naerling wrote: It seems to me that constantly creating all those objects, configuring them etc. seems like a lot of work. So it would seem to me that it is easier to create a class that requires some parameters in its constructor, has some methods and functions that manage all the just mentioned classes and simply gives a resultset using something like DBClass.Execute.
That's a lot of assumptions on how the code is going to be used. I'm launching a few IDbCommands on a single IDbConnection (or two), sometimes in transaction, sometimes in a separate thread.
Naerling wrote: At this point, is anyone really disagreeing with me?
Or do you really agree and know some other stuff that just calls to be put away in a programmer friendly class? Smile
Lots of extension-methods from the Tips & Tricks section, like the StringBuilder-extensions[^] 
I are Troll 
|
|
|
|
|
Thanks for the tip on extensions, I'll look up some more. I'm not quite familiar with extensions yet, so that should be interesting
I think that when you're creating a shell around some classes, like in the case of DB access, you often lose some flexibility or even functionality (depends on what you want with it and how much time and effort you put into creating your shell). But the big pro to doing this is that it saves time and effort later on.
And the question remains if it is even a con that you lose functionality if you weren't using the functionality in the first place. Let's say your company ONLY uses the command object to execute stored procedures (some weird company policy), even for simple select statements, would it really be that bad if you would build a class that does not support the CommandType.TableDirect or Text anymore? Perhaps your company would even encourage it, so people are not even tempted to break the SP's only policy
It's an OO world.
|
|
|
|
|
Naerling wrote: And the question remains if it is even a con that you lose functionality if you weren't using the functionality in the first place.
You only loose functionality if you demand that "only" those routines are allowed to do database-access. I don't see any value whatsoever in such a restriction.
Naerling wrote: Let's say your company ONLY uses the command object to execute stored procedures (some weird company policy)
I'd be looking for a position in a different company - I wouldn't want to work at a carpenters shop where they only use 2-inch nails either, always becomes a mess
Naerling wrote: would it really be that bad if you would build a class that does not support the CommandType.TableDirect or Text anymore?
Yes, simply because you're obviously not familiar with the consequences. There's always a use-case that doesn't fit the "neat" scenario, otherwise you'd bu simply using Microsoft Access (it offers most functionality most db-applications tend to generalize)
What happens when I need to load a lot from the database? You could write routines for all cases, but then you'd prolly end up with more than a "few" routines. That's where objects win over procedural programming; we can recombine with it all as required, and I could replace the database with a plain textfile by providing my own IDbConnection.
I are Troll
|
|
|
|
|
I agree that's a good idea; however, having access to all the individual classes and objects gives the programmer/designer much more flexibility. Perhaps you could write such a class and also create an article showing how useful it would be to the developer community.
I must get a clever new signature for 2011.
|
|
|
|
|
Thanks for your answer. Read my answer to Eddy Vluggens answer. Perhaps you don't want that kind of flexibility or you prefer simple and quick access over flexibility.
I'll see if I can cook up some sample class.
It's an OO world.
|
|
|
|
|
Naerling wrote: Perhaps you don't want that kind of flexibility or you prefer simple and quick access over flexibility.
Not quite; the point I was trying to make was that using such an all powerful database class removes the flexibility that may be needed in some applications. However, in some cases that would not be needed so your proposed class would be the ideal tool. As always it's "horses for courses": use the tool that is most appropriate for the job in hand, but remember that it may not be the best tool for every occasion.
I must get a clever new signature for 2011.
|
|
|
|
|
|
I encourage your quest for knowledge however your youthful inexperience is not allowing you to see the decades of knowledge and refinements to this subject that have proceeded you. You don't understand the concepts necessary to compile a useful library using good OOD techniques, and based on my experience, no one with six months is capable. I was not, and understood that. As Richard was trying to point there are many more considerations that need to be addressed, simply "wrapping" an object or methods in a simple interface (BTW its called a Facade Pattern) isn't enough. You need to consider things like containment or aggregation, extensibility, life-cycle management and disposal.
Although well-written this article adds nothing to the decades old discussion of the subject.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Naerling wrote: Article and sample project especially for you
Pity I don't want or need it.
I must get a clever new signature for 2011.
|
|
|
|
|
Richard MacCutchan wrote: I agree that's a good idea; however, having access to all the individual classes and objects gives the programmer/designer much more flexibility.
If I understand that then it is an over generalization.
I doubt there is going to be any measurable subset of people that would need functionality that exists in the area that NHibernate covers which the tool doesn't cover. I suppose it is possible that there is in fact no functionality that it does not expose.
Not to mention of course that just because one uses NHibernate it doesn't preclude one from using a different idiom in that very rare circumstance (if it ever occurs) where it is insufficient.
|
|
|
|
|
Sorry, but I have no idea what you are talking about. What is NHibernate and how is it relevant to my original comment?
I must get a clever new signature for 2011.
|
|
|
|
|
Richard MacCutchan wrote: Sorry, but I have no idea what you are talking about. What is NHibernate and how is it relevant to my original comment?
As I read your comment it was suggesting that a layer reduces access to functionality which would be otherwise available if the layer did not exist.
The OP mentioned database layers as as an example of that. NHibernate is popular open source example of that. It is a .Net port of java Hibernate.
|
|
|
|
|
Naerling wrote: At this point, is anyone really disagreeing with me?
Nope.
Adding abstractions which make your code more easy are always good. But keep it in mind, more generalization will make lot of trouble and you will end up layering over and over to satisfy all the requirements. And these kind of abstractions won't help you on other projects as each project will have different requirements. So if you plan you generalize too much, you will end up writing another ORM tool like hibernate.
An interesting read : Law of leaky abstractions[^]
Best wishes,
Navaneeth
|
|
|
|
|
+5, read the article some time ago, been some valuable explanation
I are Troll
|
|
|
|
|
Thanks for the article. I'll be sure to read it later!
It's an OO world.
|
|
|
|
|
Its a simple design pattern named as "Facade"
There are low level functions available in an API, but you might need to expose simpler interfaces to your "common" users; those who need very generic functionality. For specific cases, the users may take the pain of going deeper, but 95% of time, its not required.
Hence wrapping an intricate functionality into a simple API (the target of Facade design pattern) provides both common as well as specific users the level of functionality desired by them.
OOPS has lots to learn, and the more experience you get, the deeper you can think. Its good you want to get into design in 6 months and you would sure grow up to a happy professional Cheers
(BTW: include design patterns in your quest, they would tell u a lot how things are designed)
|
|
|
|
|
Thanks for your reply.
Actually this topic is already a few weeks old. I have read up on various OOD principles and design patterns and it already helps me in day to day coding. I have not looked into the Facade Pattern a lot yet, but I will certainly do so. The problem with this pattern for me is where do you keep the line between abstract and real implementation. It seems really hard to make a Facade Class 'Closed for Modification, but Open for Extension.'
It's an OO world.
|
|
|
|
|
how to access share without mapping in code behind (windows apps)?
|
|
|
|
|
A unc path? Is this a trick question?
I know the language. I've read a book. - _Madmatt
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
