Basic tier object design questions
-
There is a debate going on at work right now. Basically we are going to be creating some new tier objects; for the sake of simplicity, just assume basic stuff like a business tier, data tier, etc). The business tier will have objects like a Orders object (that will return order info) a customer object (that will return customers), etc, etc. Is it typical for someone to want to create tier objects as an executable vs. using .dlls? What would be the pros to using an executable in a tier instead of a .dll? Also, can you pass back collections, datasets, etc from an .exe to another .exe? Admittedly, I've never tried. The proposed architecture: Client.exe would call a tierobject.exe would call a datalayer.dll I can think of many reasons why I would think doing this would be a bad idea, but I am also trying to remain open-minded. Thanks for any insights to the gurus out here.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
-
There is a debate going on at work right now. Basically we are going to be creating some new tier objects; for the sake of simplicity, just assume basic stuff like a business tier, data tier, etc). The business tier will have objects like a Orders object (that will return order info) a customer object (that will return customers), etc, etc. Is it typical for someone to want to create tier objects as an executable vs. using .dlls? What would be the pros to using an executable in a tier instead of a .dll? Also, can you pass back collections, datasets, etc from an .exe to another .exe? Admittedly, I've never tried. The proposed architecture: Client.exe would call a tierobject.exe would call a datalayer.dll I can think of many reasons why I would think doing this would be a bad idea, but I am also trying to remain open-minded. Thanks for any insights to the gurus out here.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
Your business model objects will be in a separate project. As an stand alone exe, it will have nothing to offer. No Main method, no UI etc. I see no point in making it an exe.
Jon_Boy wrote:
Also, can you pass back collections, datasets, etc from an .exe to another .exe? Admittedly, I've never tried
Yes. If they are public or are returned by some public method yes. You will just need to add reference to that exe in calling project.
"Your code will never work, Luc's always will.", Richard MacCutchan[^]
-
There is a debate going on at work right now. Basically we are going to be creating some new tier objects; for the sake of simplicity, just assume basic stuff like a business tier, data tier, etc). The business tier will have objects like a Orders object (that will return order info) a customer object (that will return customers), etc, etc. Is it typical for someone to want to create tier objects as an executable vs. using .dlls? What would be the pros to using an executable in a tier instead of a .dll? Also, can you pass back collections, datasets, etc from an .exe to another .exe? Admittedly, I've never tried. The proposed architecture: Client.exe would call a tierobject.exe would call a datalayer.dll I can think of many reasons why I would think doing this would be a bad idea, but I am also trying to remain open-minded. Thanks for any insights to the gurus out here.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
With .NET, you can use an EXE just like a DLL... So there's nothing stopping you from doing it this way. Of course, there doesn't seem to be much of a point to it, in your situation. I actually did something like that, but my situation was a bit different... It went something like this: ScriptingInterface.exe Application.exe BusinessLayer.dll ... For normal use, you would just run the Application.exe... But there were certain tasks, intended to run once a day or in special situations, that were located in the Application.exe (Though they mostly wrapped routines and models from the business layers). Initially, they were being triggered from menu options, but eventually we wanted to automate them by hooking them up to a scheduler... So basically, the ScriptingInterface.exe would reference Application.exe, and use command line arguments to perform one of those menu-driven tasks, without actually opening up the GUI. C:\> ScriptingInterface.exe Maintenance DailyRoutines RunSomething translated to...
namespace My.Namespace.Maintenance
{
public static class DailyRoutines
{
public static void RunSomething()
{
}
}
}So, there are scenarios where you might want to use an EXE like a library, but for a business layer? Probably no point.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
With .NET, you can use an EXE just like a DLL... So there's nothing stopping you from doing it this way. Of course, there doesn't seem to be much of a point to it, in your situation. I actually did something like that, but my situation was a bit different... It went something like this: ScriptingInterface.exe Application.exe BusinessLayer.dll ... For normal use, you would just run the Application.exe... But there were certain tasks, intended to run once a day or in special situations, that were located in the Application.exe (Though they mostly wrapped routines and models from the business layers). Initially, they were being triggered from menu options, but eventually we wanted to automate them by hooking them up to a scheduler... So basically, the ScriptingInterface.exe would reference Application.exe, and use command line arguments to perform one of those menu-driven tasks, without actually opening up the GUI. C:\> ScriptingInterface.exe Maintenance DailyRoutines RunSomething translated to...
namespace My.Namespace.Maintenance
{
public static class DailyRoutines
{
public static void RunSomething()
{
}
}
}So, there are scenarios where you might want to use an EXE like a library, but for a business layer? Probably no point.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
There is a debate going on at work right now. Basically we are going to be creating some new tier objects; for the sake of simplicity, just assume basic stuff like a business tier, data tier, etc). The business tier will have objects like a Orders object (that will return order info) a customer object (that will return customers), etc, etc. Is it typical for someone to want to create tier objects as an executable vs. using .dlls? What would be the pros to using an executable in a tier instead of a .dll? Also, can you pass back collections, datasets, etc from an .exe to another .exe? Admittedly, I've never tried. The proposed architecture: Client.exe would call a tierobject.exe would call a datalayer.dll I can think of many reasons why I would think doing this would be a bad idea, but I am also trying to remain open-minded. Thanks for any insights to the gurus out here.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
The only point i can see of making the different layers into exe's is if they're running as a service and you want to have one point (bottleneck?) of entry. This would naturally be the case if the client resides on one box while the server (tierobject) resides on another. That doesn't mean there won't be dlls involved for the interfaces between the layers though.
"If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams