|
Looks like your Imager class is general purpose enough and you've used IOC to provide the the smarts. Seems logical to me.
/ravi
|
|
|
|
|
I am beginning a basic shop floor control system for a client who currently consults giving advice on optimizing manufacturing processes. My problem is that he uses very broad and vague terminology in descriinbign requirements to me, and I would like, ideally, to consult some reference models or diagrams or such systems, but Google research is proving quite slow and not to fruitful.
For example, my client uses the term 'machine' for what I have found out could rather be called a 'work center', and has no term for what I have found out should be called a 'work center'. Adding additional tables required for a nice system design but don't feature in his paper design adds more challenge. What do I call the definition of 'the process done by a work center to produce a product (or BOM item)' etc.
|
|
|
|
|
There's no guarantee that the client is using accepted terminology. What you might want to do is to include a definitions section in your documentation that ties the terminology down; we've done this in the past and it's surprising how well it works when the client uses 6 or 7 terms to describe exactly the same thing.
|
|
|
|
|
Pete O'Hanlon wrote: There's no guarantee that the client is using accepted terminology.
Never mind a guarantee; there's hardly even a vague suggestion that he is using accepted terminology. I'm trying to find a nice taxonomy I can use for candidate terms we can agree on and move forward with.
I found Openbravo[^], an open source ERP system, which is very promising. Will look at it tonight.
|
|
|
|
|
I believe Oracle ERP documentation is available online. Try Googling for that.
|
|
|
|
|
Oracle documentation can be found here[^], (EBS, MRP, basically the whole line of their products) and I've been banging my head on the desk for the last 3 days trying to find any documentation even remotely useful.
I'm working on a highly-customised E-Business Suite (so maybe lack of documentation shouldn't come as a surprise), and I need to call some APIs to automate some tasks (No, I don't need help, yet  )
All I'm saying is, Oracle documentation is     , but it might prove useful for your MRP research terminology
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
I've been a developer for many years. Lately doing a lot of VB6 to VB.Net conversion work. Mostly database driven desktop WinForm apps using SQL. I want to update my design work to current best practices (I'm old school) but there is so much to choose from I'm really confused. I've broken my questions down into fundamental parts for clarity.
1. The use of N-Tier architecture appears best. In my case 3-tier (GUI>DB IF>DB). Do you agree? Other advice?
2. I currently use datasets with filtered databinding. I see Linq, SQL queries and Entity Framework as newer options. Which might be better? Combination? Other advice?
3. Can you point me to good examples of good architecture and coding methods? I'm currently studying Northwind.Net. Other good examples?
I know this is a broad question and answers may be personal choice but any guidance is greatly appreciated.
|
|
|
|
|
dhofferber wrote: I've been a developer for many years. Lately doing a lot of VB6 to VB.Net conversion work. Mostly database driven desktop WinForm apps using SQL. I want to update my design work to current best practices (I'm old school) but there is so much to choose from I'm really confused.
Ditto 
dhofferber wrote: 1. The use of N-Tier architecture appears best. In my case 3-tier (GUI>DB IF>DB). Do you agree? Other advice?
I dislike any database-application that has more than three tiers, just to be able to say that they have tiers. The DB is already a layer, it's an abstraction I can build on without regard for the logical structure on disc. The UI is a layer in my book, and the two are simply woven together. No fancy ORM unless there's more than 10 tables. No unused layers, no layers that are merely glue and pass the info blindly to their neighbours. KISS, as simple as possible. You do not want to maintain a layer and have to test that extra code if it does not provide an additional benefit.
dhofferber wrote: 2. I currently use datasets with filtered databinding. I see Linq, SQL queries and Entity Framework as newer options. Which might be better? Combination? Other advice?
Sql92, using the IDbInterfaces, on a virtualized datagridview. I do use Linq, but only for manipulating in-memory collections.
dhofferber wrote:
3. Can you point me to good examples of good architecture and coding methods? I'm currently studying Northwind.Net. Other good examples?
What do you define as an "architecture"? I like the architecture of CSLA.NET, but usually stick to something that can be found on MSDN. Architecture is a broad subject, and the basic models are well known; there's enough examples on client/server, three-layered database-apps and webservices. A valuable addition to the architecture of the current applications was the Managed Extensibility Framework[^].
Northwind has a successor, called AdventureWorks.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks for the well thought out response. Microsoft is pushing the Entity Framework with DbContext for all new development. They actually say that datasets have reached an end.
Any thoughts? Anyone?
P.S. I'm talking about an Entity Framework example called Northwind.Net
|
|
|
|
|
|
Hi
Maybe checkout Domain Driven Design (DDD) and some O/RM like Entity framework or NHibernate. There are some more lightweight persistence frameworks if these are too much (Dapper for example).
Common to these frameworks is an attempt to consolidate core business logic into a domain model. That way you can concentrate on the interesting code and make it testable. Perhaps some Test Driven Design (TDD)?
//Jonathan
|
|
|
|
|
Thanks Jonathan. My research so far is leading me to Entity Framework - Code First. EF 5 now includes data binding and automatic migrations (db Updates) both of which were needed. Code First seems to be the preferred method and best supported. Linq to Entity or Linq to SQL both look good for the queries.
I have been reading about Test Driven Design and like the concept. Writing code to fail and then fixing it seems a bit odd at first but I understand why it could work.
|
|
|
|
|
All the questions you have asked are hard to answer without business requirements.
My personal opinion is use whatever technology you understand best and is best for the job. The important gotcha with this is you also need to spend time learning new technology all the time (but really? is that not required anyway?).
Also, the biggest suggestion of technology and pattern practice I can give anyone is Inversion of Control or Dependency Injection. It is absolutely amazing what you can do with it and it is really simple to implement. It also promotes decoupling and good design/seperation of classes. Makes the lives of Dev and Test a million times easier hands down.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
I am looking for a formal requirements software tool that is based on Microsoft TFS and does not have its own database (I don't want to manage two database and application servers). I have found few tools like IBM Doors and Borland Caliber but they both have their own database. I think it would be best to have only one application server and one database server - ie Team Foundation Server. Any ideas?
|
|
|
|
|
Patricia.Jones0123 wrote: I think it would be best to have only one application server and one database server
I think that is hardly relevant. What value would it add?
Patricia.Jones0123 wrote: I have found few tools like IBM Doors and Borland Caliber but they both have their own database.
Choose the best based on your needs, not based on their architecture. There's little chance you'd be working on the architecture of the product anyway. Further, it really limits your choices enormously - there aren't that many formal requirement tools, and exotic wishes usually mean an expensive in-house implementation traject.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Quite a while ago Microsoft published a book "The Microsoft Windows User Interface Guidelines for Software Design." Later on there is a document that applies to guidelines for Windows Vista/7 guidelines for UX.
Now that Metro is out, is there any such document from M$ that spells out guidelines for UI/UX design conventions with WPF/Silverlight?
Sincerely Yours,
Brian Hart
|
|
|
|
|
You can find out quite a bit from this[^] page.
|
|
|
|
|
I have three tables, ClaimEvent, Event, and EventScope. The actual ClaimEvent can be relevant to an entire claim, or a single property within a claim. Every property has a claimId.
As such, I have designed my tables like this:
Event
id | Int Identity AI
name | varchar
scopeId | int
EventScope
id | Int Identity AI
name | varchar
ClaimEvent
id | Int Identity AI
eventId | Int FK to Event
targetId | Int
date | DateTime
My idea is to use the targetId field in the ClaimEvent table to refer either to the Claim ID (if the event is relevant to the entire claim), or the Property ID (if the event is relevant only to the current property). If I want all events relevant to the selected claim, including properties within that claim, I can just match the targetId field with the id field in the property table when the scope is "property wide". Alternatively, I would have to design the table like this:
ClaimEvent
id | Int Identity AI
eventId | Int
claimId | Int
propertyId | Int?
date | DateTime
With the propertyId field frequently being null. However, I would be able to force FK constraints to the Claim and Property tables, which I can't do otherwise. The data is all going to be entered through a data entry form, with drop downs and very little possibility of FK violations, but it is always possible.
What do you guys think? I am always a fan of minimizing fields that will often be null, especially when I can repurpose another field, but it feels a little hackish.
Cheers, --EA
|
|
|
|
|
eddieangel wrote: What do you guys think? I am always a fan of minimizing fields that will often be null,
Then move the propertyId to it's own table, and only insert a record when it's not null. Link back using the ClaimEventId to which the propertyId belongs.
eddieangel wrote: especially when I can repurpose another field, but it feels a little hackish.
..repurposing a field sounds hackish indeed
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
I like the idea of having the two distinct fields, for claim and property.
As you said, you can apply constraints cleanly to the Claim and property tables which is a definite plus, but also the null value property does have a meaning - it refers to all the properties of the claim and not just the claim itself.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
I prefer the second approach. There's nothing wrong with a field often being null if it actually is often 'null', i.e. no specific property, which is true in this case.
A lookup which goes into one of two tables is weird and should only be done if there's a very good reason to. I have had to do it in a real application so I won't say 'never', but that was a bit uncomfortable. I don't see that this is a case where that's true.
The only other sane way would be if claims and properties made a tree structure in one table, and you could just use an ID into that table. But I doubt that that is the case, because claims and properties are different things.
|
|
|
|
|
There is a parent - child relationship between claim and property. Every property does have a claimId already. So in theory when looking to get all claim information (with properties) I could write:
SELECT * FROM ClaimEvent
WHERE targetId = @ClaimId
OR targetId in (SELECT id FROM Property WHERE claimId = @ClaimId)
That would get all of the event dates that I need, I just don't like to have to use the IN query if I could avoid it. In actuallity this is going to be accessed through LinqToEF so it is going look more like:
var propertyIds = _db.Properties.Where(p => p.claimId == _claim.id).Select(p => p.id);
ObservableCollection<Property> claimEvents =
new ObservableCollection<ClaimEvent>(_db.ClaimEvents
.Where(c => propertyIds
.Contains(p.claimId) || c.claimId == _claim.id));
If the table had claimId and propertyId it would look like this:
ObservableCollection<ClaimEvent> claims = _db.ClaimEvents.Where(c => c.claimId == _claimId);
I don't really think I like the additional overhead of the subquery (In this case the addition of var propertyIds due to L2EF limitations). Anyways, thanks everyone for your input, I am going to go ahead and add the propertyId field to the ClaimEvent table. I suppose I could go so far as to have ClaimEvent for Claim specific events and PropertyEvent for property specific events, and I might end up doing that, though it irks me to add yet another table.
|
|
|
|
|
eddieangel wrote: In actuallity this is going to be accessed through LinqToEF so it is going look
more like:...
You don't design a database based on how many characters a query takes so what is your point?
eddieangel wrote: I don't really think I like the additional overhead of the subquery
Because the tables will have hundreds of millions of rows? Or because you will be doing these queries hundreds of times a second?
In either case you then design the database based on performance/volume needs - specifically.
And if not then there is no measurable much less significant overhead so it doesn't matter.
|
|
|
|
|
I think I might have only gotten a partial view of your post because while I see the criticism I don't see anything helpful.
Was it only a partial post?
If not, thank you for your input. --EA
|
|
|
|
|
eddieangel wrote: I don't see anything helpful.
In either case you then design the database based on performance/volume needs - specifically.
And if not then there is no measurable much less significant overhead so it doesn't matter.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
