|
Doesn't matter - you can use them with desktop apps as well - I've done it.
|
|
|
|
|
|
Hello there,
I am currently working on a project with a 3-tier datamodel.
The client will connect by a WCF as a custom services (NOT using IIS)
The Goal is to handle in a "central" way the data handeling an validation.
I looked at different technology's but I cannot put all the pieces togetter
I looked at using Datasets at the Business tier:
Which can nicly validate data on columns and rows
I looked also to DAAB as the Data tier. But looks to limited to me. But Maybe I am wrong
So decided to look to the Entity framework. Which looks nice to me. But it lacks data validation.
So though to combine that with Datasets but no idea how to do this.
Thx.
|
|
|
|
|
We tend to do this by using a custom validation engine, which hooks into the business layer, and provides configurable rulesets. Done properly, this is a highly flexible and highly scalable architecture.
|
|
|
|
|
|
That's a good example. Paul knows his stuff.
|
|
|
|
|
Hi,
I have a class as under:
public class ExampleClass : BaseClass
{
public int ExampleMethod(int _toValidate) {
ExampleValidator(_toValidate);
return 1;
}
}
The ExampleValidator method is contained in the BaseClass. It is used to validate the parameter _toValidate. The ExampleValidator check is very important and every method in the class ExampleClass should contain it. I want to create a unit test for this class ExampleClass, to test if every method does contain the ExampleValidator. How can I do that?
Can reflection help me?
Regards,
ap.
|
|
|
|
|
I'd like to learn more about the optimum color depth for .NET Windows Forms over Citrix connections. I'd prefer 256 (8 bit) for performance but some would like to use skins with some fancy colors if need be. Any ideas, pointers where I can learn more?
the confused are confused beyond confusion
|
|
|
|
|
Has anyone out there actually used inversion of control containers *within* compiler implementations yet? I know that by design, compilers need to be very fast, but I've always been curious about how IoC/DI could affect the construction of a programming language--hot-swappable syntaxes, anyone? 
|
|
|
|
|
I've never come across any, but it does sound an interesting concept.
|
|
|
|
|
Pete O'Hanlon wrote: it does sound an interesting concept
Yes, it does sound very interesting.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Hi all,
In many situations I've encountered applications that are built using multiple tiers but user identification is limited only to few of these tiers (this is the opposite how I've usually done). For example in 3-tier approach, UI knows the user, calls to business logic are authenticated for example using Windows authentication, but commonly the database does not have any knowledge of the actual user executing the original request.
What I find disturbing in this scenario is that data protection in database (in my opinion) should be as critical as in any other layer (or even more critical). Also knowing the actual user in the database gives many possibilities that cannot easily be solved in middle-tier.
The question is: If you could share your opinion, which approach would be better and especially why? Should the actual user be used all the way down to the database or only between client and middle-tier?
Just to clarify, the question is not how to implement either scenario (that's already figured), but what are the pros and cons in either case.
Cheers,
Mika
modified on Saturday, September 20, 2008 1:27 PM
|
|
|
|
|
Having the actual user at the database level may be nice but it also presents a management complication in that now the database must be aware of all the users that could access the application. Usually, this level of restriction isn't practical.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Good point, thanks!
What if account management is centralized (with small effort). For example Windows environment + SQL Server this could be done using AD (applies also to several other databases) or even using logic in middle tier (in heterogenous environments). Would you still consider this an overhead?
The need to optimize rises from a bad design
|
|
|
|
|
If you could centralize it to specific AD groups and assign that group privileges in SQL Server it would probably work without too much overhead. This, of course, restricts you to running only in environments that have AD implemented.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
That's true and not always acceptable.
Thanks for your answers!
Mika
The need to optimize rises from a bad design
|
|
|
|
|
In the traditional 3-tier setup, the only thing that "should" be performing data operations is your business logic. Permissions may not necessarily make sense at the data level.
As an example a "loan manager" may have permission to "approve loans". The loan approval process may update a loan record, an audit table, salesman perfomance/manager performance/sales funnel tables, etc, etc.
Granted, there will always be "update contact details".
I generally find granting permissions based on roles/interactions causes less friction in implementation, especially when dealing with workflow and interception. Quite a few times I've seen teams struggling with a "well, it goes into the approval state, so you set user to read-only, the group to "managers", and make it read-write...".
|
|
|
|
|
Thanks for the answer!
I just realized that my question is missing some relevant information.
In no situation I will grant permissions directly to users. Sometimes I've used implementation where the connection from middle tier to the database doesn't use user info at all as traditionally is done, but sometimes I use user information at all levels. In those cases typical building elements may include:
- user identification at client (AD based or not)
- secure identification and authorization to middle tier based on client user
- connection to database for the business logic, but identified by user info (in other words BL connects to the database on behalf of the user)
- database roles granted to the user
- database roles granted to the application (BL) etc...
Object privileges in the database are always granted to roles.
After that description, do you feel that the overall idea is getting better or worse?
Mika
The need to optimize rises from a bad design
|
|
|
|
|
As soon as you start connecting to the database as a different user (assuming basic .Net/SQL server/ADO) then you will break the connection pooling, which can be a performance hit.
In a moderately complex application, if you look at CRUD operations at table level, then you might find that just about every user has full access to most of the critical tables anyway :/ So you don't really gain much at that level.
Some people would say to do everything via stored procedures and permission these up...
I'd tend to put the security at the business logic level. You can even use the declarative security attribute thingos on methods called by the presentation layer if you like. :P
|
|
|
|
|
Thanks, I got your point.
These were excellent things to consider. Especially since in some cases it's benefitial (or even critical) to identify the user in the db and the side effects can be managed.
Side-note: Actually I don't break the connection pooling and it's still very elemental in the application. Only the 'level' of pooling is changed but the pool itself must remain (or else there will be lot's of angry users )
Thanks again,
Mika
The need to optimize rises from a bad design
|
|
|
|
|
This is a tough one...propagating user definitions from the UI down to the database level often makes database administration a nightmare. We use application-defined "users" at the database level to reduce this issue, and copy UI user names into database records to maintain an audit trail (and don't let most users anywhere NEAR a direct connection to the database server and its schemae).
|
|
|
|
|
Actually the db administration doesn't seem to be problematic since the whole process of creating a user is part of the application logic, but that's still a good point.
Thanks,
Mika
The need to optimize rises from a bad design
|
|
|
|
|
I am exploring an idea I would like to research further and am wondering if anyone else has any thoughts.
For high performance web applications the database and data access code is often heavily optimised, using near and far caches, distributed caches, optimised queries, optimised data access code and so on. The database is usually separate from other TP systems that the organisation runs its business on, and if not could/should well be.
It occurred to me that the reason we use far distributed caches is mainly to avoid
a) Relational/object conversion overhead
b) Disk access overhead
I had been doing some reading about new generations of universal memory (NRAM,MRAM,FeRAM), some of which is commercially available and will eventually replace SRAM,DRAM,SDRAM,Flash,etc as a universal type of non volatile high speed memory. I wondered how this would affect architecture of high performance systems. It then occurred to me that we could use (the now cheaper) solid state hard drives (SSDs) that use standard DRAM with internal UPS and backup devices in the meantime.
I thought - in this case, the need for the far cache would be reduced or removed completely. In fact, if the distributed cache could handle transactions and concurrency, and if the web app was geared less to set based operation and more to CRUD operations, then this 'advanced cache' would, on non volatile high speed memory, serve also as the primary data store.
In short, an Object Database that was mature enough to deal with transactions, clustering and a few other things, deployed on machines with DRAM based SSD's could remove the need for a far cache, an RDBMS, data access logic, etc completely, and boost performance.
There do exist Object DBs that permit SQL based relational queries, though I would imagine that many of these queries would be done for transmitting data to other systems and therefore could be done using the web app's own API.
So, in summary, what I'd to explore is this architecture for high availability large scale systems:
a) Web Farm running web apps with near caches
b) Distributed Object-Relational database on DRAM based SSD as backend
c) Separate API for datapumps to RDBMS for queries, integration etc
What do you think? What problems do you foresee? Would you imagine large performance gains?
|
|
|
|
|
Which of the following is a better design? Why or Why not?
Private Sub CheckCheckBoxes()
CheckBox1.Checked = True
CheckBox2.Checked = True
CheckBox3.Checked = True
End sub
Private Sub UncheckCheckBoxes()
CheckBox1.Checked = False
CheckBox2.Checked = False
CheckBox3.Checked = False
End sub
Or
Private Sub CheckUnchecCheckBoxes(ByVal checkValue as Boolean)
CheckBox1.Checked = checkValue
CheckBox2.Checked = checkValue
CheckBox3.Checked = checkValue
End Sub
Or
Private Sub CheckUnchecCheckBoxes()
Dim checkValue as Boolean = GetCheckValue() ' Has the logic for whether to be checked or not
CheckBox1.Checked = checkValue
CheckBox2.Checked = checkValue
CheckBox3.Checked = checkValue
End Sub
|
|
|
|
|
They are all bad designs. What happens if you add a new checkbox? Have a read around on patterns, and see why this set of implementations is bad. BTW - those are really bad names for your checkboxes.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
