When dealing with database stuff in an Enterprise Application is it always neccesary to use business objects? Is it the ideal model?
Printable View
When dealing with database stuff in an Enterprise Application is it always neccesary to use business objects? Is it the ideal model?
In a general sense, I would say yes, but the extent would largely depend on the scope and size of the application in question.
Its ideal and I think it should always be used if the size of the app warrents it.
The database can be thought of as the third tier, then some classes for your business object and validation rules, etc. for your second tier. Then the GUI and some lite processing would be your first tier. Sorry I listed them in reverse :D
hm
where have you listed them RobDog?
He listed the three tiers backwards
1. The acutal GUI (its exe)
2. .dll classes and functions for business rules validation ect.
3. Database
You can have other tiers inbetween but then it becomes a n-tier application.
I am actually looking along the line... :D
1. Presentation Layer
2. Business Logic Layer
3. Data Access layer
4. Database
Your presentation layer is basically the exe. The business logic can reside in just the exe, the exe and a dll, or just a dll. Data access layer would be a dll. Database = Database :D
How about?
1. Presentation Layer = Exe
2. Business Logic Layer = dll
3. Data Access layer = dll
4. Database = database
Yes, but you may want to place some of the simple basic business logic validation in the exe as it will help keep it simpler and less traffic to the dll.
HI i am also new to business trechnology
i am searching some guide how to develop the project with good business logic knoWlegde.
if u know any information about it please mail me
[email protected]
You probably dont want to post your email addy as it will get spammed. Members can contact you via your profile's email property.
You may want to look for a good book if you want to learn it from the basics on up to advanced.
We've used a unique approach to the layer concept - we are 5 years into this project and so far it's proven to be a truly great method for us.
1. Presentation Layer - extremely lightweight UI - nearly 100% business logic free. MDI parent - child form app. Child form is "blank" - derives the textbox, combobox, flexgrid, option and checkboxes to be displayed from the database. The child form is cloned over and over again as many times as a user selects a form (or different form). Menu of what forms are available built at runtime - from the database.
2. Business/DAL layer - all stored procedures. Named in a way that "self-binds" them to a form. A form might be referred to as frmUser, for example - sprocs all called frmUser_xxxx. frmUser_View, frmUser_Inquire, frmUser_Update. This layer is extensible to the nth-degree. You can have a cell in a flexgrid be populated or validated by a sproc - frmUser_View_Role could be associated with some column in a flexgrid on that form - again self-binding. If a textbox is called "Username" then the parameter to the sproc is called "@Username" - basically the technique to self-bind.
3. Database - MS SQL server
With this layout we can create a new "maintenance form" for a user with about 10 lines in a FORM_T table, one line in a FORMNAME_T table and at a minimum - 3 SPROCS (view, inquire and update). With that said, we can create new functionality in our app in about 30 minutes - and have it in the users hands - without an update to the UI executable at all.
Our UI executable can handle any line of business - we do school admin software, payroll and accounting products for towns, labor union (health claim processing through union dues). The same UI is used for all our different business lines - so if we enhance the UI to handle some neat new feature then it's available to all the business lines immediately.
We have an even more unique approach ;)
1. Presentation layer - These are ASP.NET pages of course, and they are empty.
2. Presentation Rendererer layer - These are class libraries which the presentation layer references, which contain the logic for rendering the ASPX pages.
3. Business Object layer - Duh
4. Business Object renderer - Yes! That's right. Each Business Object and its properties are tagged up, and this renderer, using System.Reflection, reads the Business Objects required on the page, and renderes them according to a fixed set of rules. For example, a property which is a collection can be rendered as a listbox. This is the juiciest part of the code. I usually start licking the screen when I am working on this part of the project.
5. Original Framework - The base classes and interfaces that define everything else in every other part of the project
6. Data Access - Duh, but not quite. This also generates any connection information and data access information based upon information in the Business Objects layer, so that the queries are generated without having to write any code in the data access layer. It's done automatically, and the only work required at this point is to create an SP for it.
Nice - I don't do asp pages, so I cannot fully appreciate it...
But I see a similarity - as much extensibility as possible with as little coding as possible.
You WILL use ASP.NET in the near future. I am predicting it. And then you'll never turn back to winforms. And you will thank me for predicting it. And give me lots of Mountain Dew. :(
*sigh*
I believe it ;)
btw - give me a little primer - what does the asp.net page run within? Or is it simply VB.Net code running itself? Is your app LAN or internet?
It's basically HTML pages with the 'logic' in the codebehind. For example, you can have WebForm1.aspx. This will contain all your html and asp.net markup tags such as
<input type="text" id="txt1" runat="server"> <-- standard HTML
<asp:TextBox id="txt1" runat="server"> <-- ASP.NET specific
Now, these controls have their own events, such as textchanged, or click events, which can be handled in the codebehind: Webform1.aspx.vb
These .vb files are just like in C# and VB.NET winforms, they are classes which inherit from a slightly different model... system.web. They are limited to what HTML standards are limited to in functionality.
So instead of a winform with a textbox and a button, you would create your html page with a textbox and a button, handle the button's click event in the codebehind, and place all your logic/operations/processing there.
The best part is, thanks to this separation of code from UI, the possibilities are extensive. You can even create your own HTTP Handlers for search engine optimization, with HTML/HTM extension, but generated dynamically!
So you run in a browser?
Any sacrifices - is focus as "controllable" - can you use ENTER, for instance, to move from screen object to screen object?
Yes, in a browser. Control such as what you asked for is possible, but all this falls under the domain of javascript and DHTML. You can handle the enter keypress for individual textboxes for example, and pass the focus along to the next textbox. (Of course most people just use tab ;))
I've got this requirement that most of my users are clerks - loading things like health claims, for instance...Quote:
Originally Posted by mendhak
That TAB key looks pretty on the keyboard - with it's <| and |> symbols on it...
but it's miles away from any other useful keys (the the keypad).
And that mouse - if I require it's use, the masses rebel!
But this is heading off topic. I always planned on having different/several UI's available for our architecture.
I like that kind of a setup too, in those cases I use web services where all the logic resides, so that the front end can be replaced by winforms or webforms or dumbforms or any other forms that anyone can come up with.
I've made a sample project, I hope you guys will check it out and provide me some feedback... It's in my sig... :)
Isn't this architecture and so is SZ's architecture against the 'new' MS Smart Client Application Platform? That is it cannot be taken off-line and still work? Just clarifying...Quote:
Originally Posted by mendhak
All I see isQuote:
Originally Posted by dee-u
http://img209.imageshack.us/img209/1...rpenter5nx.png
That is correct. Web only. And I should've mentioned that this entire architecture is a mistake. A tragedy of ideas. An abortion of code. I didn't mention it earlier as I was probably trying to outdo szlamany :pQuote:
Originally Posted by dee-u
and the culmination of that truthQuote:
Originally Posted by mendhak on Feb 19, 2006
http://www.vbforums.com/showthread.php?t=499030
WPF? XAML?Quote:
Originally Posted by dee-u
Not yet - I'm to busy churning out new product...
It's a lot more then just taken off-line. The "rich" atmosphere is needed that a winform gives. That is what was lost as business went to html delivered solutions.
I kind of think I was visionary in all this anyway! We spent 3 years developing a thin-client UI (even more then three!) - all in VB as a winform - so that we could deliver to thousands of users with as little requirements as possible. Our "presentation foundation" is still the reason we can churn out as fast as we can.
Today was a great example of that. We have a receipt system for municipalities. You come and buy a dog license and give them $10 dollars - you get a receipt. All this then feeds into accounting - yadda - yadda.
Now one of the departments that's using it want to "pre-create" the receipt prior to getting the $$'s - kind of like an INVOICE - that the person will then come pay against.
Copied 19 lines in a FORM table. Copied and renamed 6 scripts for VIEW, INQUIRE, UPDATE and such. Took 5 minutes. New screen now in the UI available to any and all users.
That was our goal when we created our twist on architecuture - and we are very productive with it.
I've removed it already since I am currently developing an application which uses the architecture, I am unsure if I'll violate NDA's if I'll continue posting the sample... :-(Quote:
Originally Posted by mendhak