|
If the user needs to add/edit/remove company types, then you have to use a lookup table. An enum is hard-coded, and whilst it can store values that aren't defined, they will only ever show as numbers.
Rather than having undeletable types, why not have a flag indicating whether the type should be shown on the navigation bar? That way, you give the user more control over the application.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I'm curious, do you use varchar(MAX) for every text field?
And I can't improve on Richards answer 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
In this case yes. Once I get further into the design I may make the field sizes more fixed. For now I don't really know how big these fields need to be.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I studied the design patterns book written by the Gang of Four when it first hit the shelves in the mid 1990's and I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage.
Do you use design patterns on a regular basis?
In your view, has it fallen out of favor in the industry?
If you use patterns regularly, do you have a source or sources of new patterns?
TIA
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
MikeTheFid wrote: Do you use design patterns on a regular basis?
Yes, and you probably do too. People tend to forget that a design pattern is just a formal name and description of a solution to a problem that crops up frequently. It's a convenient shortcut for conveying a solution to the problem; it's quicker to say "use a factory" than to describe how a factory works - but ultimately you would end up writing the same code.MikeTheFid wrote: In your view, has it fallen out of favor in the industry?
Nope. As evidence, I would point to Angular (which uses MVVM heavily) and ASP MVC (the clue is in the name).MikeTheFid wrote: If you use patterns regularly, do you have a source or sources of new patterns?
Code Project, GoF, articles, peers and many, many other sources.
This space for rent
|
|
|
|
|
MikeTheFid wrote: In your view, has it fallen out of favor in the industry?
You'll find patterns throughout the .NET framework, from strategy to decorators.
MikeTheFid wrote: If you use patterns regularly, do you have a source or sources of new patterns?
There is no single authority, so you'd always have multiple sources. If you have the patience, then YouTube is an option. I prefer books, like Manning | SOA Patterns[^] 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The "patterns" are out there and are being used; whether the "users" realize it or not.
What did NOT happen, was that we'd all be sitting around "talking patterns" (like architects talking about "flying butresses" and the like).
The odds of finding 2 people in the same room who CAN talk patterns is zero.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: The odds of finding 2 people in the same room who CAN talk patterns is zero.
I would not state that during an interview
At Cadac (previous employer) there's an architect that will take over the whiteboard and start explaining how the group of devs is going to build an application; it is assumed that everyone is at least up to date on the most used patterns. You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
That was ONE person doing the "talking" ... "previously".
And most "architects" rarely "implement"; they usually impede.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: That was ONE person doing the "talking" ... "previously".
The way you phrase that so carefully makes me feel uneasy, and I have no clue why 
Gerry Schmitz wrote:
And most "architects" rarely "implement"; they usually impede.
That's the task of the manager, not the architect.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Yes, but does that really relate to what GoF defines?
Following is the GoF definition for "Factory Method" (there is no "Factory").
"Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiations to subclasses."
Lets look at "Abstract Factory". The GoF definition.
"Provide an interface for creating families of related or dependent objects without specifying their concrete classes."
When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above?
If it helps note that the GoF also says the following about a "Factory Method"
Use the Factory Method pattern when
- a class can't anticipate the class of objects it must create
- a class wants its subclasses to specify the objects it creates
- classes delegate responsibility to one of several helper subclasses and you want to localize the knowledge of which helper subclass is the delegate.
As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
|
|
|
|
|
jschell wrote:
Yes, but does that really relate to what GoF defines?
I'd seriously wouldn't know, I don't go there often
jschell wrote:
When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above?
No, just the generic idea, otherwise he would specify exactly what the requirements are. If he doesn't, then it is up to the developer to choose the most appropriate solution - which usually means going for the simplest thing possible (whilst still only returning an interface).
..but when in doubt, simply ask 
jschell wrote: As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
Depends heavily on what is required; do you want a static factory, a singleton, or would you prefer an object? If it has to be combined with an object-manager pattern, then I'd think that the object is preferred. Do you want one object, or do you want multiple objects? In the first case, all objects created in the factory will be available over the manager globally. In the second case, only those objects are available that the specific factory created (in that thread).
Point is, you don't want to explain how a "single point of creation in code" can save you from having to update a 1000 references in code where there's normally a "new"-keyword. That's the problem that a factory solves, with the trade-off that one introduces a tiny bit of overhead (in terms of execution).
It is not just something you learn to impress during the interview, they're simply descriptions of a way to solve something. Lots of "developers" here would struggle with a undo/redo pattern, while others simply request a memento-pattern.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
All true, but in terms of the OP the specifics of what is in GoF doesn't seem to really have been all that useful useful.
|
|
|
|
|
Seems like a collection of formalized descriptions of some common patterns, but without much explanation.
I don't think the website is meant as a source to learn those patterns; that is what their book is for
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Seems like a collection of formalized descriptions of some common patterns, but without much explanation.
Ok, but I was actually referencing the book. The copy of the book sits on my shelf above my computer. Been there for years.
|
|
|
|
|
Quote: The "patterns" are out there and are being used; whether the "users" realize it or not.
Patterns like the "copy/paste"- pattern and the "do it fast and Dirty"- pattern 
|
|
|
|
|
Or brain patterns: scales; fretboards.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
As has been amply pointed out, people do use code libs whose structure is based on the instantiation of design patterns whether they know it or not.
My question was more about "do you use patterns," but I get and agree with your point.
Once one has an understanding of the more common patterns, one starts to see them everywhere; kind of like buying a make and model of car you've never owned before and then suddenly seeing them on the road everywhere.
Thank you to those who responded. You have been helpful and have convinced me it's time to reacquaint myself with the subject. I also appreciate the links.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
MikeTheFid wrote: I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage.
Because the reality is that most of those patterns have little usage in the vast mess that is implementation.
Not to mention of course that singleton, which is the only one used a lot, tends to be used incorrectly a lot as well. So that didn't help much.
MikeTheFid wrote: Do you use design patterns on a regular basis?
In the generic sense, not the book, yes.
MikeTheFid wrote: If you use patterns regularly, do you have a source or sources of new patterns?
My head. And not as rigorously as GoF defines it.
I looked at several of the follow on books to the GoF and found that most were really struggling to find patterns. That along with how seldom I had seen (even then) most of the patterns in the GoF didn't really bode well. Further experience seems to have supported my determination that although the idea was valid it just wasn't prevalent enough to attempt to normalize it.
|
|
|
|
|
jschell wrote: Not to mention of course that singleton, which is the only one used a lot
The decorator is used throughout the .NET framework (streams), as well as the command-pattern, factories (DbFactory, ThreadFactory), strategy-patterns, object-managers..
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: The decorator is used throughout the .NET framework (streams),
Yes I stand corrected. It is used in other frameworks and languages as well. Perhaps percentage wise used more correctly as well.
|
|
|
|
|
Hi All,
I want to create software for education like wordshark and numbershark but not sure what language to use java or C#
Thanks for your help
Ch
|
|
|
|
|
Whichever you're better at. If neither, then either will do.
|
|
|
|
|
I have recently started exploring DDD and planning to use it. I am looking for some clarifications for which I have created a sample problem and designed a solution using DDD followed by some questions. Please go through it and revert should you need further details.
Problem Statement: Architecture a manufacturing station for Vehicles which allows assembling of different parts and creating a vehicle.
Architecture Style: Domain Driven Design (DDD)
Domain terms and relationships
- Manufacturing Station may have 0…* vehicles
- Vehicle may be a Car/Truck etc.
- Vehicle may have Engine, Transmission, Wheels, Music Player, Rear View Camera, etc
- Engine could be of Petrol/Diesel
- Transmission could be Auto or Manual
- Wheel may have Tube or Tubeless Tyre
- There may be millions of parameters within a vehicle such as Speed, RPM, Tyre Pressure.
- A group of parameter belong to a certain component (Engine, Transmission, Wheels, etc).
Hierarchical representation of System
- Manufacturing Station
o Vehicles
Car/Truck
• Engine (E)
o Petrol/Diesel
• Transmission (T)
o Auto/Manual
• Wheels (W)
o Tube/Tubeless
• Parameters (Could range upto millions)
o Speed - E
o RPM - E
o Coolant - E
o Tyre Pressure - W
o Audio Level
o RearCameraOn
o DoorLocked
DDD Solution
Bounded Contexts (Identified)
Station
Vehicle
Engine
Transmission
Wheels
Bounded Context Details
Bounded Context – Station
Aggregate Root
o Station
Slots : List<slot>
Entities
o Slot
o Vehicle : Car/Truck
Value Objects
Repositories
o StationRepository
Services
o SlotService
Events
o VehicleAllocatedToSlot
o VehicleDeallocatedFromSlot
Bounded Context – Vehicle
Aggregate Root
o Vehicle : Car/Truck - How to manage inheritance and new vehicle types such as Bus
Parameters: List<parameter>
Entities
o Registration
o Chassis
Value Objects
o Manufacturer
o Model
o Parameter
Name
Value
Type
Default Value
Unit
o Audio System
Repositories
o VehicleRepository
Services
o AssemblingService
Events
o VehicleCreated
o VehicleDeleted
o VehicleRegistered
o VehicleDeregistered
o AudioSystemAdded
o AudioSystemRemoved
Bounded Context – Engine
Aggregate Root
o Engine
Parameters: List<parameter>
Entities
o ElectronicControllingUnit
Value Objects
o Gas Pump
o Valve
o Filter
o Fan
o Parameter
Name
Value
Type
Default Value
Unit
Repositories
o EngineRepository
Services
Events
o EngineCreated
o EngineRemoved
o FilterAdded
o FilterRemoved
o FilterReplaced
o GasPumpAdded
o GasPumpRemoved
o GasPumpReplaced
o FanAdded
o FanRemoved
o FanReplaced
Questions:
- DRY is violated. We could see Parameter defined in almost all the services.
o Is it advisable to have a separate service for Parameters? In that case, does a component(Engine Or Wheel) keep a list of parameter id within itself OR each parameter hold a parent Id? - How does a client create a Car with Engine,Transmission and 4 wheels in a single call?
- How does the relationship between different components achieved? Fo e.g how does a specific engine know to which car/truck it belongs to? How can we reconstruct a car/truck?
- How to manage inheritance depth using DDD?
o Vehicle -> Car -> Ford/Toyota? - How to manage deep level composition using DDD? How do we flatten the aggregates?
o Station -> Car -> Engine -> Fan -> Parameter(Fan Sped) -> value
Station.Car.Engine.Fan.Speed How to retrieve Speed(Parameter) value in other Bounded context
Thanks in advance!
|
|
|
|
|
Praveen Raghuvanshi wrote: I have recently started exploring DDD ...Architecture Style: Domain Driven Design (DDD)
Had to look that up and I can say is...versus what other idiom exactly?
If you are not designing for the domain, then you are not solving the domain problem. Seems like there is no alternative there.
So any process that reaches a solution of the domain would be DDD. Anything that doesn't would be, by definition, a failure.
Praveen Raghuvanshi wrote: Domain terms and relationships
Hard to read (you could format it) and seems likely (guessing on a quick look) that you have an entity model. If so then you should start with the entities themselves first, before adding details (attributes.) Then add major attributes to clarify functional needs. And likely skip non-significant attributes at all for the model (they are implementation details.)
Praveen Raghuvanshi wrote: o FilterAdded
o FilterRemoved
o FilterReplaced
Domain modeling should start with the actual/real domain.
Above doesn't represent a real domain. When you build a car from scratch you don't remove nor replace the filter. If you service a car you might replace it, but that is not part of building the car from scratch.
Modeling the entire real world eco-system of manufacturing to servicing is too large for a single model and would not be approached that way.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
