|
Thank you very much. I liked your answer.
|
|
|
|
|
Just to play devils advocate, couldn't you argue that the EmployeeDBDataContext is in fact your DAL and the code snippet should be part of the BLL?
If the purpose of the DAL is to allow you to change your data source without affecting the business logic, then I would say the EmployeeDBDataContext achieves this.
"You get that on the big jobs."
|
|
|
|
|
Thank you very much. Yes, thats a good question. Actually, I spent many hours just to find out if that given code snippet should be a part of BLL or DAL. Yes, if I place that snippet in BLL, then, the auto generated LINQ to SQL data context can be the DAL. But, in my BLL, I wanted see the object, not the LINQ to SQL Data context. Because that data context is auto generated and I will have to depend on what Microsoft gives. That is much uncomfortable for me. But, I learned in many place that, Projection should not be done in DAL. Query is a Business Logic. So, the dilemma is kind of a headache and brain killing. Finally I decided to encapsulate the DataContext in DAL and the DAL will not do any projection. DAL will return a single row of a entity or a collection of entity. My BLL will use that collection of entity and use LINQ to Object to do any projection as needed. Even according to that decision, yes, you are right, the above snippet should be in BLL. I should have asked a collection of employees in DAL from BLL and then, the BLL would filter out with the email Address for the desired employee object using LINQ to Object. Hmmm Brain got jammed again 
|
|
|
|
|
Definitely with Entity Framework, LINQ to SQL and alike have blurred the borders but even in more traditions architectures, the presentation can still be exposed to the entities which encapsulate the data. There is no reason why a DataGrid in the presentation can't display a collection of entities.
It looks like LINQ is querying your DB but if the DataContext is actually your DAL then LINQ is actually querying your DAL. LINQ just offers a flexible approach to communicating with the DAL as opposed to the old way of having to write a method (in the DAL), for every possible permutation the BLL may request.
So instead of the DAL deciding what the BLL can and can't request. The DAL just provides access to the data source and describes the data. The BLL is free to do what it is supposed to: decide what the presentation can and can't access.
What I have just said may be technically wrong but that's how I see it conceptually.
"You get that on the big jobs."
|
|
|
|
|
My collegues and me just had the same discussion this week.
Why do all the extra work if you could simply directly get your data from the DAL?
Well, I think that this is because sooner or later your client is going to call and they want some new functionality or improvements.
So now you have one form where your employee is called, but in a few months you will have two forms.
If you seperate your DAL from your UI you then could simply re-use that same BLL you used earlier. If you did not seperate your UI from your DAL then you will find that:
A. you need to type some code containing logic (either the LINQ query or validation logic) twice.
Or B. you'll have to make a BLL after all to not resort to solution A.
Solution A is definately not good practice and if you find your clients demands rising you will type more code multiple times.
Even worse, if the client wants the logic you now build into different forms to be slightly different, you are going to have to edit all forms that use this logic, and this is easily forgotten if your application is getting larger.
But you do not want B either, because it will cost you a lot of time (first decoupling DAL from UI and then build the extra layer).
So building that extra BLL might look like a lot of work now, but it could save you a lot of work in the future.
Hope this helped. Good luck with it 
It's an OO world.
|
|
|
|
|
Thank you so much for the ideas. Yes, you are right and thats what I am realizing now. At this moment, I am avoiding the extra BLL layer, but I will keep a sharp eye when duplication of code is apparent, and only then, I will add the BLL with only the refactored common methods. So, some of my UI will call DAL and some of my UI will call BLL and over time, depending on BLL will be increased and DAL dependency will decrease.
|
|
|
|
|
I'm interested to find out if it is better to have multiple (8), small services within a solution or to have less but larger services.
Our service currently has around 40 model/dal classes (each model class has a dal class), this represents the bulk of the solution but I can see it growing by another 50% before we are done. I'm debating breaking it into smaller services although there is not logical segregation of the database, it would be breaking it to redusce the size only.
Is there a significant impact on the server to run multiple services. Each client will need all the services b/c of the homogeneous nature of the data.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
One entry/exit point for your service is better, but then I would dispatch the logic behind it in several classes with each their own logic/domain etc.. So basically a bit of both 
|
|
|
|
|
hi all,
for my college project, i need to do a a risk and return analysis for information systems. for that i need to use the cost of some of the software application (a rough number with a valid reference).
can anyone help me to get the cost for some of these applications with a valid reference. even if you have personal experience in this is also fine.
Applications
1. a normal website
2. online consortium
3. marketing and Promotion monitoring system
4. Demand forecasting system
|
|
|
|
|
Without any kind of specifications that info is totally useless for you. I can make a normal website for €100, but also for €1.000.000. That goes for all 4 points.
|
|
|
|
|
if i can give you some basic specifications can you tell me the cost.
please give me some valid reference, so i can cite it. since this is an assignment for my college.
these systems are suggested for a click and mortar company. a book retailer.
1. website
they currently have a website, what needs to be done is they should provide a login to the cargo company who handles their delivery service to check the orders. so they can manage their delivery better.
2. Online consortium
this is a web portal to support online group purchasing. they can join with few other local book retailers. and addition to that this portal should also help them to manage their corporate customers (they have universities and colleges).
3. marketing and promotion monitoring system
this is to manage their promotional activities and to monitor most profitable marketing channel.
4. demand forecasting
based on their sales a system to focus their demands on each branch.
Please help me on this.
|
|
|
|
|
I think the idea may be for YOU to create a high level specification of the requirements for each type of web site, then try and estimate the costs. Asking for references and links is just lazy!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
nz_hmz wrote: 1. a normal website
That depends on the speed of your team and the size of that "normal website". Their speed is dependent on knowledge, routine, motivation, cooperation, and a whole lotta more variables.
nz_hmz wrote: 2. online consortium
More time than a normal website. Depends on what a consortium turns out to be
nz_hmz wrote: 3. marketing and Promotion monitoring system
Sounds like a standard database-application. Any experience with those?
I are Troll 
|
|
|
|
|
A Risk and Return Analysis isn't typically a software development document. I was curious and it appears to be something found in the financial industry.
If it is a financial course you are studying can't you just make up the figures and reference make-believe quotes you received from make-believe software companies?
Otherwise what you are asked to provide is a mammoth task. I'd get clarification from the teacher first.
"You get that on the big jobs."
|
|
|
|
|
I agree that it ain't directly connecting to the computer science approach, and sounds more likely to be a marketing approach. But I guess he ask on a development forum in the fact that he doesn't know the software price estimate variables... But as Eddy say's, its a combination of many variables related to a giving project.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
