|
Welcome to CodeProject ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
Take some time to look through the forum list and try to find one that more specifically matches your problem. It seems your problem has nothing to do with Design or Architecture. Many of the forums are specific to languages and/or platforms and it seems that is the problem you are dealing with, how the tab control works and perhaps the IDE you are working with.
led mike
|
|
|
|
|
Hi,
How can I design a business use case diagram?
I know how to design a use case diagram, but what is business use case diagram?
I'd searched the web, but I did't give my answer.
Best wishes
|
|
|
|
|
|
Uses case fundamentally has two kinds: business use case & system use case.
Both have same way of presentation and almost same templates.
If you have wrote use cases more towards to defines yours system or in other words interaction between different systems or interaction with system and human then they are more towards system use case. (e.g presenting available menus and their interaction).
Business use cases are more towards to define business (e.g presenting available menu and their broad view of features)
You should take another try to search material into web, lots of material available
Akash
|
|
|
|
|
Hi Gurus,
I'm trying to create a website with scalability in mind but I'm a little stuck with ASP.NET authentication (Forms Authentication) because I simply don't know much about its internals. I wonder how high traffic websites like myspace.com handle authentication. Most pages in my application are public (i.e. accessible to anyone authenticated or not), only a few pages are only available to authenticated users. I'm basically trying to find answers to those questions:
- As far as I understand from the documentation, ASP.NET Forms Authentication authenticates every request, ie. checks for the authentication cookie and if found it extracts the authentication ticket and decrypts it, is my understanding correct? And if so, can't this potentially affect performance esp. the decryption part? Is this needed for renewing the authentication cookies? (as I believe the ticket issuance time is saved inside the ticket so probably the cookie has to be decrypted anyway to get the ticket issuance time from the ticket then compare this to the current time and decide whether the cookie has to be renewed). If this is an absolute necessity (I'm talking about authenticating every request for the sake of cookie renewal), can we use an encryption algorithm with low overhead (in web.config, authentication element), still efficient? which encryption algorithm would you recommend in this case?
- Is there any way I could make ASP.NET only authenticate requests to protected pages (=pages that are only accessible to authenticated users), BTW, in my application I don't use roles I only make those pages accessible to any authenticated user. Actually I read somewhere that I could write the code needed to authenticate the user only in those protected pages but I wonder whether I will have to handle cookie renewal in this case (this is one thing that's automatically handled by ASP.NET forms authentication)
- Any ideas how I can get the last login with a persistent cookie? In my application I want to allow users to use the "remember me" option (which will send a persistent cookie to the user's computer), now the user doesn't log on explicitly anymore, so I can't put my code that saves the last login to the database in the login page hence it's not used by the user anymore, so how can I do this? I'm thinking about one way to do it but I'm a little worried about how this could impact performance, anyway, here's how .. in my application I need some user related data so I could probably get the data from the database whenever a user with a persistent cookie visits the site (probably FormsAuthentication_Authenticate is the most suitable place) and also write the last login to the database then cache the user data in ASP.NET's cache using the user login retrieved from the authentication cookie as the key with a sliding expiration (let's say something like 30 min or make it equal to the authentication session), if the user visits another page within this period (ie. before the data is removed from the cache), I get the data from the cache and all is ok, but if I can't find the data in the cache (ie, returns null) then I update the last login in the database and get the user data again from the database and cache it in ASP.NET's cache. What do you think about this solution? Do you have any better ideas? I know I could use sessions but I read somewhere that if you handle the session_start event the session is created anyway even if you don't have and data in the session which is not really a good idea (this mean that a session object will be created for all site users authenticated or not).
- what about security? Assume my encryption was broken by some hacker, can't the hacker insert a different user login in a ticket and encrypt it with my broken encryption key? In my application I'm using the user email address as the user login, so, probably a hacker can insert a random email address (from an email list for example) in the ticket and try to access the account of that user, if the user happens to have an account on the site, this will work. My question is that, is the cookie encryption the only way for protection? Because I believe it still can be broken no matter how good it is and in this case it can be a disaster as described above. I'm thinking about something to prevent this, I might probably add something like a random code in the users table in my database (let's call it a security code) and include that code along with the user login in the authentication ticket (separate it from the user login by some character like a pipe for example or put it in the userdata section in the authentication ticket) and whenever we get the data of this user from the users table, we check for the security code along with the user login, for example:
select userid, {other fields here} from users where userlogin = {user email retrieved from the authentication ticket} and SecurityCode = {security code retrieved from the authentication ticket}
Do you think this can be reliable?
Beside the questions above, if you have any resources on the internals of ASP.NET forms authentication, I'd be very grateful if you shared them with me. I've been searching the net for a couple of days but all I can find so far is only about how to use ASP.NET forms authentication in your applications e.g. how to configure it in web.config .. etc but nothing about its internals. I also tried to use .NET Reflector (specifically to disassemble FormsAuthenticationModule) and gained some understanding about how it works internally but not enough to figure it all out.
Sorry for my really long post!
Your help is really much appreciated ...
modified on Thursday, May 22, 2008 7:08 PM
|
|
|
|
|
I have seen people using this and I don't understand why or what is the main purpose.
is it just to hide some implementations details to define such a new class (XXXimpl) and that the main one only servs to provide access to the interface functions ?
Thank you in advance.
|
|
|
|
|
I would suspect that what you are looking at is a case of having an abstract base class and a concrete implementation class. This is one of the most over abused uses of OO you can find. Basically what happens here is somebody creates a base class for something that they are only going to do once and then creates a concrete implementation of it. For some reason, they think this is going to aid them in reuse.
|
|
|
|
|
Pete O'Hanlon wrote: For some reason, they think this is going to aid them in reuse.
 You mean it doesn't?! 
I'm not sure I'd go so far as to say that, but I would certainly say it's the result of people learning "just enough" about the OO concepts to be dangerous. Without actually understanding what the benefits are and both why and when to use them, people are destined to make mistakes and abuse the pattern.
Scott.
—In just two days, tomorrow will be yesterday.
—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
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Pete O'Hanlon wrote: For some reason, they think this is going to aid them in reuse.
Probably the reason for this is because it does.
Steve
|
|
|
|
|
thank you all for your precious interventions.
indeed the recent example I found and which prompted me to post a question here was the MFC feature Pack. OK the source code is not written by Microsoft, but there was the new FrameWnd class along with another FrameImpl class, in separate files.
the frame class holds an object of the Impl type,( and visversa I the Impl object holds a pointer to its corresponding Frame window object): at least for example you can notice the following :
BOOL IsMenuBarAvailable () const
{
return m_Impl.GetMenuBar () != NULL;
}
this is a member function of the FrameWnd.
not all members are encapsulated like this, and also some memebers are public visavis the consumer of the FrameWnd class.
|
|
|
|
|
Stephen Hewitt wrote: Probably the reason for this is because it does.
You what? Why does separating a class out into an abstract and concrete implementation aid reuse? Read what I said and you'll find I'm talking about somebody splitting a class up into an abstract/concrete implementation where there is no need because it's never going to be reused. Sorry but there you go - reuse only applies if you have proper design.
|
|
|
|
|
Pete O'Hanlon wrote: Read what I said and you'll find I'm talking about somebody splitting a class up into an abstract/concrete implementation where there is no need because it's never going to be reused. Sorry but there you go - reuse only applies if you have proper design.
Yes but to be fair, you are making an assumption about the OP where there is no information suggesting this has occurred because, well there is no information at all about the project in the OP.
led mike
|
|
|
|
|
led mike wrote: Yes but to be fair, you are making an assumption about the OP where there is no information suggesting this has occurred because, well there is no information at all about the project in the OP.
Actually, I was making a generalisation. Let's not get our assumptions confused with our generalisations - that way madness lies.
|
|
|
|
|
Pete O'Hanlon wrote: Actually, I was making a generalisation
I won't argue since trying to re-read it while looking for the distinction is making me dizzy 
Pete O'Hanlon wrote: I would suspect that what you are looking at is a case of
led mike
|
|
|
|
|
Yep, its a sister pattern to the far too common Foo/IFoo pairing.
|
|
|
|
|
There are probably lots of different motivations for this, but i'll describe my own: i want to hide the implementation details of a class from the rest of the system. For instance, i may only need a handful of public methods but scores of private methods, and wish to avoid clutter or allow changes without forcing clients to recompile. Or i might use types for data members that aren't used in the public interface at all, and by relegating them to the Impl class i reduce dependencies during compilation.
Both of these become very important when distributing a C++ library in binary format, since they simplify the header files that need to be distributed along with the library (and the danger of a client becoming aware of, and relying on implementation-specific details that might not be preserved in a future release).
The technique can also come in handy when building a simplified facade for some 3rd-party libraries, since it allows you to avoid leaking details of said libraries through to your clients.
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
Shog9 wrote: i want to hide the implementation details of a class from the rest of the system. For instance, i may only need a handful of public methods but scores of private methods, and wish to avoid clutter
I agree with this as a possible reason for splitting up the implementation, but there are other ways to handle this in .NET with the use of the partial keyword.
Scott.
—In just two days, tomorrow will be yesterday.
—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
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: there are other ways to handle this in .NET with the use of the partial keyword
AFAIK, that really only lets you split class definitions across source files, somewhat akin to using macros or #includes in C++. The final, compiled type still contains everything. And since .NET doesn't use header files, you aren't really accomplishing anything by splitting up the source (well, you are, but nothing that matters to clients who shouldn't care about the source anyway).
FWIW, Microsoft used the technique (usually by way of a public bare-bones type and a sealed, internal implementation) all over the place in the framework itself, often for no apparent reason (what, a MIME parser isn't generally useful?!). IMHO, it's a technique that should be used sparingly when at all.
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
You are correct, you can only split the definition up across source files not compiled binaries. Microsoft did use that technique in a lot of places within the framework, probably a hold-over from older habits.
Scott.
—In just two days, tomorrow will be yesterday.
—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
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
thank you all for your precious interventions.
indeed the recent example I found and which prompted me to post a question here was the MFC feature Pack. OK the source code is not written by Microsoft, but there was the new FrameWnd class along with another FrameImpl class, in separate files.
the frame class holds an object of the Impl type,( and visversa I the Impl object holds a pointer to its corresponding Frame window object): at least for example you can notice the following :
BOOL IsMenuBarAvailable () const
{
return m_Impl.GetMenuBar () != NULL;
}this is a member function of the FrameWnd.
not all members are encapsulated like this, and also some memebers are public visavis the consumer of the FrameWnd class.
|
|
|
|
|
MS does things like that a lot to avoid supporting them. A MIME parser would be useful - but the one they have may be crap. Better to not give your clients a MIME parser at all, if you suspect its quality might be a bit suspect.
|
|
|
|
|
Hi to all,
This post is to claim for your wisdom and experience, I’m developing an application that provides certain standard functionalities: inventory management, orders, invoices, accounts receivable, etc. (I’ll call them core functionality) The problem here is that features solves the 90% of my customers requirements, BUT always need to make some customizations in order to fit each customer policies and special processes. So, the main challenge here is to design an architecture that allows me to make customer specific changes (most of the time they affect the database structure adding fields and/or tables, changing their corresponding UI’s for entering or viewing these new fields, adding validations, etc) without duplicating the core functionality, so if I made a fix or enhancement to the core functionality I’ll be able to distribute the changes to all my customers.
I hope I explained it clear, I already tried many alternatives but none likes me at all, hope any one can help me, I’m sure most of all ever have an scenario like this, when the customers says “all is great BUT it needs just some “little” changes to fit me 100%”. At this time I’m at design stage, so I’m wide open to fresh ideas.
Thanks in advance, regards
|
|
|
|
|
And here lies some of the worst and best designs ever inflicted on the user community (to say nothing of the poor bastards supporting the application)
In most cases I use an Item/Attribute structure as Product/Size Attribute/Measurement Attribute. This is all very well until you require discreet processing for a particular attribute type.
You are getting to the core of the OO design philosophies and you need a book no a library to cover the subject. trying to find a "correct/best" design is like picking the best beer or the correct indexing strategy.
Hopefully it will stimulate an interesting thread (or be completely ignored)
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You're right, OO is supossed to solve these common challenges, and in theory it does, the problem comes when trying to get it into practice in a really complex system. Until now I solved using not OO techniques but tricks to parametrize the code, so I have all my customers speciall code in the same source and it's enabled or disabled at run-time. I know it's not an elegant or OO way, but it's the only way to reduce a little the maintenance.
What I'm looking for in this thread is to get some ones experience and different ideas to find an better OOper and elegant solution, hope that could happen
Regards
|
|
|
|
|
For an application like this OO concepts will only take you so far. Effectively what you are looking at building is an extensible framework that allows third-party customizations without the need to change code. Systems like this can be built but they are not trivial.
You need to start at the framework level and build your core framework in a very well structured way. Even though your core components are related to one another, I would build them as separate pieces as much as possible and provide the hooks necessary for them to interoperate. You also want to make sure that you have a robust data layer.
One approach that I have used in the past is to build things up in layers. I had a data layer that understood XML (and XML only). The data layer had the responsibility of parsing that XML and inserting data into the database and also taking data out of the database and putting it back into XML. My business objects were effectively specialized dictionaries.
The flexibility in the user interface is also going to be a challenge, although if you can guarantee that certain elements will always be there (and in the same layout) you can take advantage of the visual inheritance capabilities offered through Visual Studio. (This is nothing more than regular inheritance where your base class is a visually designable "thing" (like a form or user control). As long as that base class is not abstract you can visually design the derived class in VS just like you normally would.)
As for distribution of changes/fixes, you need to make sure everything is built in a very modular fashion (separate DLLs or assemblies for each component). That will allow you to update specific portions as needed.
If you want to go beyond this and actually implement a system that allows for this without code changes you need a lot more work and design as it will require publishing type services to update the database, which will also require conflict resolution to ensure that you don't remove user-made customizations with an update. From there the problem gets more complex as your business objects must be written in such a way as to be able to expose an unknown number of properties and metadata. The UI then needs to know how to render those objects in a completely dynamic fashion, with rules that govern how that layout works in the face of an unknown number of properties. All of that is possible, but definately not trivial.
Scott.
—In just two days, tomorrow will be yesterday.
—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
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
