|
In evaluating cost of a job take into account Albert Einstein : Not everything that can be counted counts and not everything that counts can be counted.
Piccadilly Yum Yum
|
|
|
|
|
Hi All,
I'm in the middle of making a complete demo system (possibly for a new Code Project article but more for practice at the moment) whose design should be very robust and scalable. I have a question regarding security and how best to implement it, not on a detail level but a high level design bases. The security is going to be pretty run of the mill stuff, hashed passwords, users, roles, permissions.
The system currently uses the AdventureWorks demo database for it's data and comprises the following components:
Database SQL 2008 R2 (Express)
DAL (using LinqToSQL but will migrate it to use Entity Framework)
Wpf Client (using PRISM)
Silverlight Client (using PRISM)
WCF Services
Basically I want a unified security model so that all code components (or future components) will use exactly the same security mechanisms. Which leads on to the first question. In the past I have created separate security databases and also just created tables in an existing schema to support the required security model. I would ideally like to be able to assert that the calling user has rights at the stored procedure level AND at the code level but by having a separate database for security means that that the data database starts to have a dependency on the security database which I'm not a far of.
Baring in mind that there will be plenty of security going on at the code level does the database even need to worry about rights? Some projects I've worked on have insisted on this level of security. I would ultimately prefer security at both levels so even if someone managed to get a connection to it they still have barriers to getting anything meaningful out of it.
Any thoughts on this or links to good reading would be appreciated.
Cheers,
|
|
|
|
|
My take on this is that security controled at the DB level is for the absolutely paranoid but may have its merits in some situations. If DB roles as in SQL Server are used this can be alleviated but the user (role) still has to be granted access (or a login for the user in a specific role).
|
|
|
|
|
I've actually opted for a completely different tact. I'm going to leave the database security alone as there simply isn't a one size fits all solution.
I'm also going to make use of the Windows Identity Foundation and implement a claim based security model. Keeps it all flexible.
|
|
|
|
|
A few years ago I was using MSMQ to provide a durable messaging solution but I don't see much noise about it these days. Has MSMQ been superseded and if so what are the new techniques for providing durable messaging?
Architecture is extensible, code is minimal.
|
|
|
|
|
MSMQ is still very much in active use. It's just not talked about as much, and is generally hidden behind abstractions such as WCF.
|
|
|
|
|
I'll preface this by saying that I'm not exactly a DB programmer, though I've been doing more and more of it lately.
Say you have a typical database with Products, Customers, and Orders tables. The Orders table is an associative table with foreign keys to Products and Customers. Standard fare. You have a UI front end for the database with views for viewing many records and views for viewing/creating a single record.
A customer calls to place an order, so the operator fires up the Create Order form to enter the data. On the form are the controls for entering the data, like textboxes, checkboxes, etc. Once the order info has been entered, the operator hits the Submit button, and the order is added to the Orders table.
However, the Orders table is an associative table, so the info for entering the customer ID as well as the product ID needs to be correct, i.e. the values entered into those fields need to correspond to an existing customer and product respectively.
My question is what are some ways in which this can be implemented in the UI? One could use list boxes for the customer and product so that the operator can easily choose values from those tables to enter in to the order. However, this approach doesn't scale well. There could be thousands of products and customers to choose from. Putting them all into list boxes isn't really going to work. Maybe instead some type of table view that can popup to let the operator choose from it?
How is this usually handled in DB applications with a UI front end?
|
|
|
|
|
|
You are right, drop-downs and lists don't work so well when the list gets longer.
In the past I have worked on systems that give the user some sort of search facility (a button they can click that pops up a screen to let them search with wildcards, that sort of thing). That works for pretty much any size of data set.
More recently, auto-complete or auto-suggest have become popular (the user starts to type and the system suggests matching values that gets refined into a shorter list as the user types). That works quite well for larger data sets than you might think.
Or, you can subset the information based on something else they have filled in (for example, entering a postcode or zip code brings up a list of street names and house numbers that match, which is a manageable list size once you have even a partial postcode).
|
|
|
|
|
I like to use auto-complete but you need to consider a few CRUD issues like when new customers are added etc. In a multi-user environment with many thousands of customers this may not be an option, in which case validating the entry is a better solution. Typically the UI will ask the model if the customer exists. If not the UI needs to manage the situation and ask the user if it is a new customer or provide a drop down list of possible matches i.e. Customer name "Acme" may return "Acme Sydney", "Acme Paris", "Acme London". In this scenario you can still use auto-complete just don't populate until validation returns a mismatch.
Architecture is extensible, code is minimal.
|
|
|
|
|
Leslie Sanford wrote: A customer calls to place an order, so the operator fires up the Create Order form to enter the data. On the form are the controls for entering the data, like textboxes, checkboxes, etc. Once the order info has been entered, the operator hits the Submit button, and the order is added to the Orders table.
However, the Orders table is an associative table, so the info for entering the customer ID as well as the product ID needs to be correct, i.e. the values entered into those fields need to correspond to an existing customer and product respectively.
Nice workflow. I'm imagining an MDI-app where the name of the current logged in user can be found somewhere near the edges. It's a three-step proces, so feels like a wizard. I'd generate the Sql, put it in a list, and on "Finish" execute all in a transaction, or roll back on error.
Page 1, customerselection page;
Input Textbox 1 - typing a partial name should update the grid below;
Input Textbox 2 - typing should update the grid based on soundex;
DataGridView - containing all the data relevant there, not looking much like a grid, and with full-row selection.
Next, Product registration
The exact same pattern again
Next, Order
The exact same pattern
Finnish
START TRANSACTION
COMMIT TRANSACTION
I are Troll 
|
|
|
|
|
If you are looking for a solution that can scale well you've to think about severals forms.
Following your example, if in UI you have to select a Customer or a Product, the main form (the New Order one) holds something like a textbox to hold a code that will come from another search form which performs the search between the target needed.
So, in that form you can put a set of controls and code to refine and help the search and when one is selected the "target" code is passed to the UI caller. Those search forms could be implemented in several ways (web services, dlls, etc)
This solution is analog to the windows common dialog everybody uses to select a file.
If you want to go a step forward you can build a wrapper service to ask for every searcheable entity in your database asking dynamically for the db schemas to use related fields or indexes that already exists and compose a dynamic UI for the search.
|
|
|
|
|
You could make a thing in google stile, in a textbox type a char and only products beginning with that char will be displayed, for example in a combo. Then typing one more or more char and so on, finally select the product by name by id as you like 
Piccadilly Yum Yum
|
|
|
|
|
Hi All,
Not sure where the best place to post this on the forums really.
I've been tasked with making a decision about buying a POP3 component. Anyone have any experiece with using commercial POP3 components and can share user experiences. I'm mainly looking for components with solid attachment(s) handling capabilities.
Any input would be great.
Cheers,
|
|
|
|
|
I'm mainly looking for components with solid attachment(s) handling capabilities.
As opposed to liquid attachment(s) handling capabilities ?
Just joking
|
|
|
|
|
haha ... I only deal with s*** ... 
|
|
|
|
|
|
Since you seem to be looking for a .NET component, you might have better response posting this on one of the .NET/C# forums.
|
|
|
|
|
|
Thanks for sharing
|
|
|
|
|
This is a general and basic question about object oriented design. I've been programming for many years, but just recently I've started realizing many of my old ways of doing stuff is flawed or just plain wrong in terms of good OO design.
Simple case: You have class A and class B which have some overlapping properties. You want a method that copies or converts the common properties from class A to class B. Where does the method go?
1) Class A as a B GetAsB() ?
2) Class B as a constructor B(A input)?
3) Class B as a method void FillWithDataFrom(A input)?
4) Class C as a static method B ConvertAtoB(A source)?
Thinking of SOLID principles and testability I have a hunch that 4) is the best answer, but I'd like to hear some rationale. Maybe there isn't a definite answer?
|
|
|
|
|
I would personally use a static method called "Clone",temp = YourClass.Clone();
Hope it helped... 
|
|
|
|
|
Well it's not really a clone. They have SOME overlapping properties, but they are different classes.
A concrete example similar to what triggered my question: I have a MVC-project where the model class is class A and the ViewModel is class B:
class Model
{
string Name;
string Timestamp;
string Token;
}
class ViewModel
{
string Name;
DateTime Timestamp;
}
I am not interested in showing the Token, and the Timestamp has to be converted to a DateTime class, which then is presented better by the .NET framwork's DateTime.ToString().
Where do I do the conversion? Now if I put the code in either Model or ViewModel, I will introduce a dependecy between the Model and the ViewModel. If my Model-class changes, the ViewModel must change. So my question is really if that is always a bad thing (option 1,2 or 3 from the original post). Don't they have an intrinsic dependency anyway?
|
|
|
|
|
In your concrete example, I would let the ViewModel have a reference to the Model.
In this way, you hint that the ViewModel is in sync with the Model and you don't have to duplicate data.
If you consider DateTime strictly as a presentation data type, the data model should NOT know about it. Hence, you need to put DataTime operations outside the data model e.g. in ViewModel or a data type converter.
To illustrate this cut, imagine that you MUST put your model code into 1 library and MUST put view model code into another library. Furthermore, the view model MUST know the data model, but the data model SHOULD NOT know the view model.
This is the classic MVC pattern: http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller[^]
With all that background info, either or both of the following conversion services would work:
<br />
Model model = new Model();<br />
model.Timestamp = "0227011";<br />
DateTime timestamp = model.Timestamp;
<br />
ViewModel viewModel = ViewModel(model);<br />
DateTime timestamp = viewModel.Timestamp;
Hope it makes some sense!
|
|
|
|
|
Thank you, this makes sense yes. Usually one don't have to worry about dependencies going downward in the project hierarchy, I guess. It's all this new IoC-trend that just got me rethinking a lot of the old paradigms.
Another thing - slightly related: What do you (or anyone else who care to answer) think about referencing the Name property from the Model in the ViewModel directly, instead of copying it? Would this breach some kind of archictecture/dependency principle?
So...:
class ViewModel
{
public Model ModelInstance
public DateTime Timestamp;
}
This way the View accesses the Name property directly on the model through the ViewModel. If ASP.NET: <¤= ViewModelInstance.ModelInstance.Name %>
I read an article by Rockford Lhotka[^], creator of the CSLA framework, that encourages such an architecture. I'm not convinced everybody agrees, but I kind of like it. It minimizes property duplication. See in particular the chapter "ViewModel as Action Repository".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
