We have a few dev servers, 4 staging, and 6 or so production servers.
In each one the database connections will be changed.
we had 2 thoughts:
1) ( not me ) said set the info during a build. I took that further and a build provider could be created to set them. now thats ok, but what if changes are needed. You would have to reset those and do a new build. Things change to much around here
2) ( my idea ) Extend the App Domain to custom load a config file. thats ok
Now taking that idea further. We could extend the CLR and add domain neutral assemblies ( which are slow, but cool ) but we could have the CLR load the config file for the entire company. Then every time a config file is accessed we could inject our code.
But, even better. Since we have a custom connection class. We could simply have the connection method acces the web config. Now thats a cool idea
A custom class can easily be created by a generator. Using a DAL it can populate the class easily without having to write the code in one section. With 2.0 data binding is acceptable and every data source looks for IEnumerable or IDataBinding ( simple or complex respectively). A DataSet uses an IList so you can actually fine tune the storage and using the Generics the databinding requires the same or less lines than datasets. And reading can be done with a data reader or table so the connection does not have to be held.
Also. it takes 15 lines of code to set up saving and loading to the database for BO classes via reflection( which is how QLink operates in c# 3.0). And since a BO is not a singleton pattern( well I hope people aren't designing it that way) DataSets will have the same concurrency issues that BO's will. Both have to determine if employee 2 is overwriting employee 1's changes in a web application.
But, like you said. Its something an architect will decide and depending which side of the spectrum he was trained on. Usually determines what path he takes.
Just some points I thought you should know. If you have arguments against them. I would love to hear them.
I'm like great another person who sees the light. then he writes this: 1. They amount to reinventing the wheel. You might do a better job than a one size fits all object - i.e. dataset, or you might do a worse job. In other words, setting up business objects involves work, and the results are only as good as the people doing it. 2. Business objects require you to worry about versioning - both data versioning, and business object versioning. This is a problem that is not easily solved.
But this is what versioning database should handle and will creep up you no matter what.
3. Business objects require you to write the translation layer between objects and RDBMS. This is easier said than done frankly.
Well with a DAL this is not an issue. Or with reflection easily handles this.
4. BOs require you to write a new object for a new entity - this might not be fully true as your design might encourage reuse, but you cannot beat the dataset, in which to setup the object you have to write zero code.
There are helpler tools that will do that. This doesn't require much typing tho. Also, in the dataset you dont have validation rules included.
5. Concurrency is a bigger pain to manage using BOs. This refers to both thread concurrency and database concurrency.
This doesn't really make sense. I don't think he really understands how to assemble BO's. ALthough the database is an issue. If 2 people on a web site are updating the field which one overwrites who? But this is a problem both BO's and DataSets will have. This whole number is not valid.
6. At least in .NET 1.1, BOs are not directly databindable. You have to write the code to make that happen.
Not actucally. All data sources are ILists or IEnumerables(comples vs. simple)
7. You lose any enhancements Microsoft may provide you with in future versions of .NET. If in .NET 1.1, you shied away from datasets, because of it's serialization problems, you probably spent a very long time getting your business objects working. Only to find out that MS fixed it in .NET 2.0.
Actually microsft improved data binding custom classes. And custom classes can simply extend TypeConverters to get more productive classes. And with Generics theres no typing advantage.
8. Business objects either require you to write the equivalent of a data adapter, or they encourage you to fill the object as the connection is open which severely impacts connection pooling performance. Breaking this single rule can cause your application performance to degrade by about 20 times in a concurrent environment.
Not really you can use a reader or a table or what not and build after the connection is closed. So this is not a valid argument. Plus, a business object never queries the database. Where as a Dataset will need to hit the database a lot to make sure its gets new data factors for business rules.
9. Your business objects are only as good as the underlying objects they use. Thus if you use an arraylist, you pay the boxing unboxing penalties, and removing objects from a collection is extremely expensive.
He makes a valid point, but the DataSet uses ILIsts which box and unbox also. So a class will be equal or faster depending on how you store the information. You have freedom to change in a class. The dataSet is locked.
How depressing. Apparently he has only read about custom business objects and not actually implemented them.
Plus with workflow the Dataset will be used seldomly in c# 3.0. Sometimes I wish I stayed in Java.
I made it to level 54 and changed my talents to get presence of mind.
Ohhh, man I can't wait for a high level to come mess with me now. I can do about 2k damage in the first 4 seconds of a fight. Thats a true mage. And when I get more damage gear or epics, dude I will rock.
Well anyways its great. I can go gank people and keep waiting for high levels to help. Then practice on them.
Nothing code wise happens to me anymore -- wimper
I know too much now. Everytime some sees something odd, I already know the answer.
Although I'm trying to write a regex pattern to translate classic asp pages.
And, a guy told me you just call methods to implement classes for the GridView with IEnumerable. I know thats wrong. But, I wont say anything.
Well this guy is quitting and I'm taking over his project. Its not bad cause its based on ashx handlers. But, the original guy made it in c#, and he did the rest on VB. OMG! What the hell was he thinking?
Thats and theres 20 projects in the solution.
Ohh yeah, and this HUGE project I'm taking over has a huge flaw.
They dont call dispose on the Connection object.
So eventually they will get timeouts. Duh!@
But, thier nice so I will pretend I'm not sure if thats the real reason. I have to keep the peace that way
I cant wait to start working on that app tho. The bad part is the guy I'm doing it for doesn't know much about creating real classes. He thinks the BIZ layer is actually supposed to send a DataSet to the UI. How ignorant is that? But, its a ok. Hes a friend so I will be patient. for now
Although I need to make an article for making transparent panels. Ive seen tons of questions about it.
I have code that fixes it.
Ohh yeah my Map Editor for Gameboy is coming along nicely. You can draw bitmaps over. The grid snapping isnt working out so well tho.
Gotta fix that. and I need to add 4 backgrounds and allow to rotate them. That should be easy. The drag and drop was the hardest.
This should be pretty simple. Use the same basic idea with interfaces.
I will more than likely use an error object that investigates the interface its contained in. Using reflection I can grab the events, look in the database for the validation rules I developed yesterday.
Piece of cake. Plus I can just pass an error object to the validation so the validation will be completely organized. Just like Sorting an array works.
The actual business rules will use windows workflow
And I dont care about the UI.
Although, since NO ADO.NET classes will exist. I will have to train the other guy on how to bind to custom classes. OOP is so cool. I feel sorry for newbies who don't know how to do that.
That reminds me of those people who say dont use custom classes. What are they programming in, Perl? LOL freakin NOOBS! I'm glad I dont work with them, I'd have to fire them for not understanding what OOP means.
Boy, that was an awful day. I just knew when I posted that question. I would get some morons who didn't even read my questiion. I mean I said specifically, don't tell me to use ADO.NET and sure enough. I get a bunch of noobs to the OOP world telling me that custom classes are wrong. Although the DataSet thing didn't bother me that much. But, typed datasets have proven to be a disaster. And I have a class generator, so what would be the point. Plus, DataSets are EXTREMLY bulky so its a bad decision all the way around.
I hate the asp.net forum for the simple fact that no ( except min-hpc ) has a clue about good programming. Just garage basement crap.
Man I get angry quick about that. I wish I came up with the angry coder name first. If people would read and learn then they wouldn't be such morons and I wouldn't get so upset. Maybe. But, we know that will never happen.
I have a site im building for someone. The DAL and BIZ layer will be-redistributable so heres my thoughts.
Each type of action an the DAL will have its own interface. I think about 5 totals. This way when customers use it they only get the functions I make avaliable for a particular action.
This is cool, because using an abstract factory I can dish out a particular interface based on the users credentials and the actions to be performed ny the biz layer. Its all pretty basic.
Plus, each method in the DAL will have an attribute attached that specifies what external source it accesses. The build provider can easily read these and include all the nessary resources.
That is sooo cool. Plus it will be easy to understand.
But actually the interface part. Yes about 5 interfaces and then use .net security to limit particular functions.
Not sure about that tho. The layer needs to be super fast with pooling since we expect a minimum of 300 users at a low. Maybe take out the security and left the interfaces control that. That way I dont have slow try catches everywhere
I haven't read any answers tioday so Im not annoyed
Its prolly best I gripe here instead of voicing my opinions.
First of all I think everyone I come in contact with either in person and via the internet is a damn noob about programming.
I mean I know 98% of .net and I am an extreme fan of OMG and evoltionary archecture. Which I guess is where my problem lies.
Like for instance. People don't really understand what a true layered application looks like. But I won't go there.
I have seen time after time people using ADO.NET to populate data in the UI! So if its layered then the UI knows nothing of data sources. NOOBS! Get a clue.
The other issues is I believe in a true OOP world. But it seems to me, that only developers with a java background can understand this view. Like my topic above is a gripe and first one doesn't get it at all.
So thats my problems in that I want everything to be a class and used as a class. Wheres the other people dont. And if you make a class a typed dataset its intent is no longer there. ( NOOB! )
I know Im not alone in this because several of the top bookwriters have this view. They just dont say that much about it, because the average developer will be confused and dismiss the book out of ignorance.
We need a revolution in programming design named "Evolutionary Architecture". And it gains more momentum everyday.
The first guys says this: Why use ADO.Net when you can over complicate things and write your own classes? I love making things harder then they need to be.
I mean WTF! First ADO.NET sucks and offers no real values except for grabbing data. And secondly, does he even know what a damn class is used for? Its like okay, I wont make classes and just have a 1 layered app. igrnorant and read a damn book
then the second guy said this: You can use Typed Datasets (as a DAL) then make a classes for business logic that your presentation layer will actually talk to. With the right attributes you can make it so you can set methods as datasources for GridViews and the such.
Another WTF! First of all Typed datasets have been proved to create huge programming issues and have been dropped by everyone except the noobs.
Thats my main complaint.
I even one time saw an "so-called" expert answer a question and say hitting refresh didnt cause a a postback! Another WTF! Does he even program or is this a manager thinking he knew the answer. I got into a heated debate with him insisting it didnt cause one. noob
So I guess what I'm saying is why are noobs giving advice. I mean if you have a teacher that guess at an answer and is usually wrong. Will you have a poor education. YES!!!
Thats the whole reason I quit answering questions here. Cause all the time I would watch these noobs answer questions wrong and then argue with me about what is the right answer. If you dont know, dont answer!
My gripe yesterday
1 line of code equals many bugs. So don't write any!!
Last Visit: 31-Dec-99 19:00 Last Update: 28-Mar-17 22:47