|
After reading the other posts, too, I think that you have a nice concept for your solution. Reminds me somewhat of CAB (Composite UI Application Block) where the CAB is the central part that coordinates all others, just like your Gateway coordinates DataSources and client applications.
Best luck with your approach. And maybe you can provide us with some information how it worked out in a CodeProject article - would be very interesting.
-^-^-^-^-^-
no risk no funk
|
|
|
|
|
I think you should see this: www.datumnode.com
|
|
|
|
|
Thanks for the interesting link.
-^-^-^-^-^-
no risk no funk
|
|
|
|
|
The way I think:
You need a data provider factory, which returns an IDataSource. Any new DataSource provider would be implement the IDataSource. Once you have a default implemention (base class) of the the IDataSource, you could effectively use the provider pattern to return the datasource.
Effectively, the client would talk with the factory to return the appropriate data source provider.
Now, how you talk with the factory host, could be decided on the performance, deployment plans, ease of applying updates etc. A simple webservice hosting the above mentioned factory should get your started ?
But again, it does not sound like a good idea to have one webservice datasource provider for all the applications you use unless its the same datasource which is being used.
|
|
|
|
|
With this “gateway” we plan to implement some kind of business logic – that will be common to all developers. In this case, not only “data sources will be the same” but developers will even have no idea with what database they are actually interacting with.
|
|
|
|
|
rokford wrote: To avoid this we decided to develop some "common gateway" - middle tier that will be used by all applications that need to access any data sources. Also we plan to implement WCF for this task.
I don't think I understand. You are going to run all queries and result sets through the gateway machine?
|
|
|
|
|
Not machine but by common service (or services).
|
|
|
|
|
I like WCF for the communication, but I am concerned that you are looking to roll your own gateway mechanism. The problem with this approach is that you have to cater for all situations because you can guarantee that, sooner or later, somebody will want to do something that your gateway just isn't designed to do. More importantly, they will have a valid reason for doing this, and you will either have to extend your gateway or you will constrain what they can do.
Another issue, is that there really does come a time when your application needs to know what the data source is. For instance, you may want to insert a record into a database that has an automatically incremented primary key - but not all databases support this, so you need to have some mechanism to generate the key for this database.
|
|
|
|
|
From my point of view accessing a data source and retrieving data is the task that can be formalized quite well. ADO.NET is a good example of this. Unlike ADO.NET we plan to implement some middle tier that will common for all applications (developers). So the main task is to access different data sources using some abstract model. You should not think that application "knows nothing" about database - it knows enough to get required information from database. But there will not be connection strings, stored procedures ,etc.
"Another issue, is that there really does come a time when your application needs to know what the data source is. For instance, you may want to insert a record into a database that has an automatically incremented primary key - but not all databases support this, so you need to have some mechanism to generate the key for this database."
In our company we always use stored procedure instead of direct sql statements. So in this case there must be a procedure like "insert_something" that hides away how primary key is generated - with auto increment or using sequences.Of course,it's implementation will depend on what database is being using, but at the same time it will transparent to client applications.
So we do not want to create some universal language for all databases- but organize all these databases (connection strings,user credentials,stored procedures,ets) is some abstract model and make it accessible by all applications using different protocols and communication technologies (due to WCF)
|
|
|
|
|
But you still haven't answered the question about what happens when somebody legitimately needs to do something that your gateway just isn't designed to do?
I haven't got a problem with the idea of formalizing the way you communicate with databases, this is just good design, but there will come a time when the gateway just won't cope 100%. The question I'm asking is, what is your strategy going to be at this point in time? Are you going to have a team to manage the gateway separate from the team who write the applications? It's not a good idea for the two groups to be one and the same.
|
|
|
|
|
Actually I don't understand your question. Can you give some examples?
Without it your it seems to me something like "What you are going to do if ADO.NET (.NET,Oracle,MS SQL.) just won't cope 100%"
|
|
|
|
|
rokford wrote: Unlike ADO.NET we plan to implement some middle tier that will common for all applications (developers). So the main task is to access different data sources using some abstract model.
That is what a DAL is for. There is a very good reason that a DAL is a library and not a tier. By making it a tier you are adding significant application performance penalties for a perceived benefit that is still completely unclear to me.
|
|
|
|
|
We found some interesting solution but not sure it will accommodate our needs.
http://wcf.netfx3.com/files/folders/development_tools/entry11198.aspx
|
|
|
|
|
Hi,
I'm designing a processing engine that will do the following:
1. Determine the file type, i.e .TXT;.CSV;.XML
2. Check to make sure the file being review is valid
3. Make sure the data is valid based on delimiter and based on XML parsing
4. Load to a database server or pass to some type service
The purpose of this is to enable IS to utilize this "Framework" and extend the use of File I/O functionality or XML functionality dependending on the file type selected.
My first question is where do I start?
I'm looking at the Decorator/Iterator patterns but I feel I'm only extending the File I/O.
Thanks,
|
|
|
|
|
I might have done it this way:
Have a class for each file type.
1.) Find out the class/provider which knows how to handle the given file type from the list of registerd handlers (maintained in a global variable list).
eg:= FileProcessorTXT, FileProcessorCSV etc, all deriving from FileProcessorBase.
2.) If there is no registered handlers, error!
3.) If there is a registered handler, call the virtual function Validate() which should check the format. eg:- FileProcessorTXT's Validate() needs to bother about TXT file validation only.
The above classes job is to validate, read the special file types. Now we might need to introduce a common interface to talk with the DB. This could be a class/function on the FileProcessorBase such that each of the descendants would return data in the accepted format; say based on an XML template.
O my god.. I think I just wrote a design document!
|
|
|
|
|
Thanks I appreciate your input
|
|
|
|
|
Hi,
I've been surfing around for articles on best approaches to library architecture for multiple applications used by multiple developers and so far have come up with very little so I thought I may as well just ask some questions.
Our company has been developing solutions for a number of years using Borlands Delphi and a FAT Client-style architecture where most of the code gets compiled and linked into one executable per application (There were historical reasons behind this style that I won't go into). So structuring our code library has been fairly easy, using a Visual Source Safe as our primary source control, we simply share the code into the application folder, then we reference all the code as relative path.
However, since starting development in C# (and the dotNet Framework) its obvious that this approach was not going to cut it.
So then development started and progressed down the path of separate, specific assemblies for each specific algorithm/datastore/UI etc. Now I/We have the problem of structuring these assemblies/libraries so that multiple applications reference them both in development and deployment. Deployment isn't much of a worry as we are placing all the assemblies in a folder on the target platform but our major problem is referencing these assemblies during development. Ie in Solution/Project files, VSS and also in our Build System (FinalBuilder)
I'll give you an example.
LibraryA and LibraryB are two assemblies that contain algorithms for two separate/different situations. They have there own Project and Solution files, their own specific tests, are in their own separate folders with our source control and are built separately within our Build System.
Now Application1 needs to use both LibraryA and LibraryB. Application1 is laid out in the same way that both libraries are (VSS, BuildSystem etc) but there needs to be a reference to both assemblies within the Project file. And it needs to be available at Design time (within VS) and during automated Build time (FinalBuilder).
I know about the GAC and as a company we have decided against using it.
Our preliminary idea is to use a Global assembly area of our own, that each developer has (using an environment variable) and it contains all the assemblies within our library, so all references are directed at this location. So our Build System just needs to ensure that these assemblies are available when building each application. Other ideas that have been discussed was to setup our Build System to build all dependent projects before the main project and reference each dependent project within the main projects Solution file with the references to the dependent projects build locations.
So my question(s) is/are:
What are some of the approaches that other organisations/people use to reference assemblies at design/development time across multiple applications and multiple developers?
Hopefully I have explained our problem sufficiently and I'm betting that this is a issue in more than one place of business, so I'm sure the answer(s) is out there. Please share your thoughts and ideas.
Thanks
Brett Morris
-- modified at 21:50 Tuesday 26th June, 2007
|
|
|
|
|
Why don't each of you just assemble your own custom solutions of the pieces you need and allow the build machine to do the same?
This statement was never false.
|
|
|
|
|
What is the intent of calling a virtual function in thebase class from the its overwridden version in derived class? Does it in any way relate to the template design pattern. How can the same be achieved by agrreggation.
|
|
|
|
|
You would normally do it if you needed to perform the original processing provided by the base method in your derived method. For instance, suppose you have the following really trivial classes
public class ClassA
{
public virtual void DoThis()
{
Console.WriteLine("Hello");
}
}
public class ClassB : ClassA
{
public override void DoThis()
{
base.DoThis();
Console.WriteLine("World");
}
}If you do the following:
ClassB myClass = new ClassB();
myClass.DoThis(); Hello will be written to the console, and then World on a new line.
|
|
|
|
|
Actually, cant agree with this. The purpose of virtual function is not to call the base function. You could do that anyways even without virtual specified.
The actual usage of virtual comes into play for polymorphism. In the above example, if you were instantiating the object via :
ClassA myClass = new ClassB();
myclass.DoThis();
Its the ClassB.DoThis which is going to get called. Effectively, letting you choose the functionality at runtime.
Please correct me if I am wrong.
|
|
|
|
|
If you read the OP, you will see that he asks:
"What is the intent of calling a virtual function in thebase class from the its overwridden version in derived class?"
The implementation that I show answers this question - granted I don't go into the practicalities of design and polymorphism, but I am only interested here in showing why you call the base method.
|
|
|
|
|
hey there
i use transparent canvas on my pics ,in order to use a fine background template i made
in mozilla everything is great (again) but in IE(6) i get a gray img bgrnd ,that covers up the page backround
i use fireworks 8 for image editing
Is there a body{} or html{} css rule that will solve this problem
thanks
(i hope i'm in the right message board for this)
P.
ninja coding
|
|
|
|
|
You're not on the right forum. This should be in the web development forum.
However, we're here now. Are you by any chance using a transparent PNG? If so, you should know that IE 6 has real problems with them.
|
|
|
|
|
All,
I am a junior developer at a company and I have been given a rather unusual task. We have 2 development environments, one is C# .Net 2.0 and the other is called Omnis Studio. For those of you not familiar with Omnis Studio just imagine Visual Studio on acid.
Now all of my companies legacy systems are written in omnis studio and we want to get away from that development tool. But the system that is written is a rather monolithic monstrosity that cannot be easily broken out.
We have identified a system that we want to replace within it and are about to use a .Net library with a COM facade so that omnis studio can work with it. The plan being that if we slowly replace enough then it will be more .Net than omnis and we can wholesale change it.
This is where the problem comes in. My manager wants me to write a GUI application which we then embed in an omnis form. Now I think this idea is mental and that it will end horribly. What I would like are the thoughts and oppinions of this board in regards to cross platform form embedding. What I want is to write a simple data object with a COM facade and slowly replace the middle of the system so that Omnis will merely be a GUI interface which at an appropriate time we can peel off and replace with a .Net gui. I feel that if we get into the form embedding business that we will end up with frankenstein's monster patchwork quilt of a system where when we finally decide to peel away omnis we will have a set of independant GUI's that will be as bad as what they replaced.
If people could give their thoughts on this matter I would be greatfull and any links to resources that would be helpful. To clarify my position it would be like embedding a delphi form in .Net, or a python form in ruby. I don't really see the need as the origional system already has forms and buttons and should only interface with a middle tier data objects.
Thanks in advance for any help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
