Adding layers
-
Article and sample project especially for you ;) Creating your own Wrapper Class[^]
It's an OO world.
-
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 :suss:
-
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:
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.
-
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.
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.
-
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.
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
-
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.
-
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
-
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
Thanks for the article. I'll be sure to read it later! :)
It's an OO world.
-
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.
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)
-
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.
